Maven 2 Reflections…

February 28th, 2006

Now that we’ve got XFire 1.0 out, I thought I’d write some thoughts on Maven 2. We switched to Maven 2 right before our release candidate, because the multiple Maven versions were causing user confusion. People would look at our samples and try to use them with M2, but they were written in M1. Since M2 has the idea of transitive dependencies, which wanted to produce valid M2 poms with our project so our examples could take advantage of that.

To give you some idea to the size of our build, we have around 10 different modules which produce

  • Individual jars for each module
  • A bundled jar of all the modules (but not their dependencies)
  • A distribution with the bundled jar, the individual jars, the javadocs, the manual from Confluence, and select dependencies.

There was some definite advantages in switching:

  • Our example poms ended up being quite a bit shorter because we only needed to declare a dependency or two and the rest were brought in automagically by Maven.
  • Builds were a fair amount faster.
  • The release:prepare goal rocks. It updates all the versions of your poms to the released version – say 1.0, then checks it in to cvs and tags it. Once thats done it updates the poms again to the snapshot version – say 1.1-SNAPSHOT, and then checks them in again. Very cool.

But I ran into several issues as well:

  • We create a bundle jar which contains all the XFire modules called xfire-all. The assembly plugin can’t do this right now so I had to write a MOJO to do this. While it wasn’t horribly hard, it was a bit of a PITA. Overall the assembly plugin needs some lovin to become really useful.
  • Maven is really really rigid. You must conform or use something else. While doing another M2 build I couldn’t find a way to optionally skip the generate-test-resources phase which downloaded a 6MB jar. There are certain times you don’t want to do that and just run Maven with -Dmaven.test.skip
  • Transitive dependencies really started to get on my nerves. There is no way to declare that a dependency is needed for compiling and testing, but shouldn’t be included by default on the classpath with transitive dependencies. So things like Jetty or HTTPUnit are automatically pulled in via XFire’s transitive dependencies despite my feeble attempts.
  • While release:prepare worked great, release:perform didn’t. For some reason our build froze when doing a release:perform, although I haven’t been able to track down why yet. I suspect its some bad interaction with our unit tests and surefire.
  • Building a distribution was the hardest part. There is no way to build a master javadoc of several different modules so I had to do that with Ant. I also had to do some hacks to make sure certain jars weren’t included in the distribution by the assembly plugin.

I go back and forth on M2, but I think overall it was better than if I had done the project in Ant. Give Maven a little more time though and I think it could really start to be killer. Really my gripes just focus on the assembly & release plugins, and they are aware of these issues and will be fixing them I’m sure.

Comments are closed.