Posted by kohsuke
on February 4, 2007 at 5:54 PM PST
I released Hudson 1.78, which has the native Maven2 support.
Maven 2 is really a terrible terrible tool (with all the bugs, no documentation, verbose XML, ...), yet I'm finding it more and more useful these days. Hudson is now built on Maven2, and so does the JAX-WS RI extensions that I wrote . Glassfish v3 is also built entirely in Maven2.
Since I rely more on Maven2, I wanted more Maven2 support in Hudson. It can already build a Maven project, but it didn't natively understand Maven — so you still have to specify what jar files to archive, what javadoc to copy, what builds to run once your build is finished, etc.
But since much of the information is in POM already, I thought it would be really nice if Hudson can understand POM. So I started working on this some time ago, and it's finally getting into a presentable shape. The newly posted Hudson 1.78 is the first version with this feature enabled.
When you create a new job, you'll be presented with options to choose what job type you'll create. Here I'll choose "experimental Maven2 support":
Then I specify the SCM information. Technically speaking POM contains this information, but Maven has an issue with automatic SCM setting inference, and also the release plugin touches the SCM section of the POM, so I decided that it's better to ask for SCM information from the user separately from POM.
Anyway, once you do that, Hudson checks out a workspace and recognizes modules automatically. You can run the whole project or each module separately. Modules that can be built in parallel are built in parallel (provided that you have more than 1 executors set up), and dependency among modules are recognized and used for scheduling. Build numbers among modules are kept in sync to improve trackability. Below you can see that Hudson picked up my 4 modules. It's building the core module #26 right now.
You can see that this core #26 depends on the remoting layer build #26, and it's used by the war module #26. Artifacts are archived automatically. There's no change in this build because I manually started it to capture screenshot.
It turns out that parsing POM is not really enough for Hudson, because there are many information captured in the form of plugin configuration, which is not readily accesible. So Hudson actually embeds Maven, and listens to how it executes a build. This allows Hudson to accurately determine where and when things are produced. To the best of my knowledge, even Continuum doesn't do this (instead it just hard-code kew locations, like "target/api-docs".)
Listening to build execution in the same VM allows Hudson to start recording the information while the build is still in progress. For example, artifacts can be archived as soon as a jar is created; fingerprints of dependencies can be recorded as soon as any mojo asks for a dependency resolution; test results can be recorded even during the test execution.
As with everything else in Hudson, this is extensible, so Hudson plugins can be added to listen to mojo invocations. For example the findbugs plugin would listen to the fingbugs mojo invocation and use that to record the result. The end result for the user is a lot of features without any configuration.
This is still a work in progress, so be warned, but I'd appreciate any feedback on this feature.