Here's a five minute video demonstrating how some fun features of my Maven VirtualBox plugin, such as creating a box from some configuration, provisioning it and running integration tests against it.
I've just watch a really good InfoQ video from James Lewis at Thoughtworks. As you might expect from Thoughtworks, it has some stuff about CD, but also some great ideas an building large systems from small, somewhat independent components.
I've spent a lot of time recently writing or working on plugins for Maven recently. They're simple, rewarding and fun to write. I thought I'd share a couple of tips for making life easier when writing them.
Tip 1: Separate the Task from the Mojo
Initially you'll put all the code for the mojo into the mojo's class (i.e. the class that extends AbstractMojo). Instead think about separating the task out and having minimal shim code for the mojo. This will:
I've written an API, Maven mojos and Ant task for creating, provisioning, starting, and stopping Oracle Virtual Boxes. It's somewhat similar to Vagrant or VeeWee and can be found on Github:
https://github.com/alexec/maven-vbox-plugin
When you need to have file kept on file share used in your build, but they're not suitable to deploy into your repo, you can get some of the benefits of having artifacts in a repo (e.g. sharing and versions) by creating a disk based repo on an office file share. This is handy for some edge cases, for example when you might have very large artifacts (e.g. CD images) that are too large for your artifactory, but could be stored on a file share disk.
Firstly, create somewhere shared for the repo it to live:
When writing code, you might experience the feeling that you should make all your names very descriptive, and long. But is this necessary?
"A name is too long when a shorter name exists that equally conveys the name's meaning and implication."
Long names take up screen real-estate, meaning that less code appears on screen, making it slower to work with and people more prone to mistakes, esp. in dynamic languages. Ultimately, long names create additional cost, and additional bugs.
