Skip to main content

Maven 2 integration in Hudson

Posted by kohsuke on February 4, 2007 at 5:54 PM PST

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":

newJob.PNG

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.

modules.PNG

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.

dependency.PNG

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.

Related Topics >>

Comments

Using custom workspace feature from Advanced Project Options

Hi, I've a scenario where in I need to pull in regular builds from Perforce, which in turn syncs POM.xml Once sync is done, I run the Pom.xml I see that the "Custom Workspace" option is available in Jobs that I build for Ant, but I don't find the same option for Maven based Jobs. Now Hudson somehow changes my workspace path to it's local directory and hence my pom.xml doesn't get picked up properly. :(