Top Ten Reasons to Move to Maven 3

I recently helped Dennis Lundberg prepare a talk for Jfokus on the top reasons why you should switch to Maven 3. When I work with customers setting up, or improving, their Maven-based development infrastructure I always recommend using Maven 3. I thought I'd share with you the top ten reasons that Dennis highlighted in his talk.

In a nutshell, Maven 3 is superior to Maven 2. While there might not be one single killer feature for most users, it's more a matter of several bug fixes and improvements that together make it a much better tool. Depending on your use case and your preference, some of these reasons will be more compelling than others. Here's the list.

#1. Maven 3 is the "Latest and Greatest"

Surely not the wording that you should use when selling this to your manager/boss/product owner/whatever, but when it comes to tools and frameworks many developers like knowing they are using the latest version. Maven 3.0 is where all the new work is done and where the main focus is. Maven 3 has a six week release cycle which was inspired by how things work at Eclipse. This gives you more predictability. You know that critical and serious bugs will be addressed quickly, and you'll only need to wait a few weeks before the next official release is available.

On the other, in Maven 2.x, you don't know if there will be a timely release. Bugs are fixed, but there's no sustained effort to test and push new Maven 2 releases. As an example there are 12 fixed tickets for Maven 2.2.2, of which one has been fixed for more than one year. Few developers are paying attention to Maven 2, and the focus is on Maven 3.

#2. Maven 3 Isolates Project Dependencies and Plugin Dependencies

In Maven 3, project dependencies are retrieved from "repositories" and plugin dependencies are retrieved from "pluginRepositories". Contrast this to Maven 2 where plugin dependencies could be retrieved from any Maven repository. If you strictly controlled your repositories and locked down your own project's dependencies you would often run into problems with plugin dependencies. With Maven 3, your own projects dependencies are retrieved from the declared "repositories" while any plugin's dependencies are retrieved from the declared "pluginRepositories".

This might not matter to many of you, but I see a lot of larger corporations running into this issue all the time. If you want to have strict control of your own dependencies, you can do this with the Procurement features of Nexus Professional. Procurement is important, but it also requires you to be meticulous about which dependencies you allow from external repositories. With Maven 2, because plugin dependencies can be mixed up with regular project dependencies this forces you to take on the responsibility of enumerating and allowing all of your plugin's dependencies. In a complex project this mean keeping track of hundred of dependencies which had nothing to do with your own project's dependencies.

With Maven 3, having these two repositories truly separated makes it possible to define a procured repository and a more open pluginRepository.

#3. Maven 3 Supports Extensions for Alternative Repository Layouts

With Maven 3 it is now possible to create extensions for other types of repositories than the default Maven layout. This gives us new possibilities demonstrated by projects such as Tycho, which allows you to build Eclipse plugins and OSGi bundles with Maven. If you are developing Eclipse plugins, Maven 3 makes it possible to align your OSGi builds with the rest of your Maven-based builds.

#4. Maven 3 is Easier to Embed

One of the main reasons for the major refactoring between Maven 2 and Maven 3, was to allow for Maven to be embedded in other tools. There were some early trials with embedding Maven 2, but it was simply not designed for that and a new architecture was necessary. All of you using m2eclipse are already using Maven 3 and have been doing so for a long time. Switching to Maven 3 for command line executions makes a lot of sense as it aligns the version of Maven in your tools and adds consistency between CLI and your IDE.

#5. Maven 3 has Improved Artifact/Dependency Resolution

Thanks to the refactoring of the artifact resolution logic in Maven, the existing deficiencies of artifact resolution in reactor builds with Maven 2.x have been fixed. I'm sure most of you have run into issues trying to build a multi-module project unless you execute "mvn install". The reason is that the artifacts built by the modules are not resolved from the reactor but have to exist in the local repository. One very typical symptom of this is having to configure the preparationGoals param of maven-release-plugin to "clean install" instead of the default "clean verify". Maven 3.0 fixes this and correctly resolves artifacts within the reactor, allowing you to use the default values of the preparationGoals param for example.

More on this topic can be read in Benjamin's What's in Maven 3.0 for users? blog post.

#6. Maven 3 has Improved Logging

For Maven 3.0 the logging output has been improved. It's not a major remake, but smaller changes that makes it easier to read and comprehend. The improvements include separating output from every plugin with an empty line, include the version of the plugin being executed, as well as specifying the artifactId of the project being build. The latter makes the logging output for a multi-module build a lot easier to browse. Should your build fail, the error reporting provides you with a link to a wiki page where the error is described in more details including possible causes.

#7. Maven 3 has More Intelligent Class Loading for Multi-module Builds

Maven uses several different class paths during the build, including separate classpaths for the plugins. Again, this might not seem like a big deal unless you've been burned by unanticipated side-effects of what was generally viewed as a bug in Maven 2. In Maven 2 the first execution of a plugin determined the classpath for all executions of that plugin. This often caused issues when the same plugin was used more than once during a build, and the second invocation required the use of a different classpath. In Maven 2, if you needed to execute the Antrun plugin twice in a multi-module build with two different classpaths, you were out of luck. This particular issue was a hassle for the 60 people that voted to fix issue MNG-1323 in the issue tracker.

In Maven 3.0, this issue has been fixed and every execution gets its own, isolated classpath.

#8. Maven has Higher Standards for POMs

Maven 3.0 helps you improve the overall quality of your POM and prevent future problems and errors. Aside from informing of obvious errors and omissions, Maven 3.0 also helps you adhere to best-practices by being more strict about POM validity. For example, Maven 3.0 will warn you if you haven't specified the version of a plugin used (i.e. using latest release) or have duplicated dependencies with the same POM, as it could result in unpredictable future build results.

Maven 3 doesn't just have better, more strict POM validation, it will point you in the direction of more concise and complete POM configuration. With Maven 2, it was up to you to gain knowledge of Maven best practices. When you start using Maven 3, Maven will start to provide you with some strong hints about what should be happening in your POMs.

#9. Maven 3 Supports Parallel Builds

Maven 3 didn't have a lot of new features to speak of as much of the improvement was incremental and behind the scenes. One of the very few new features in Maven 3.0 is experimental support for parallel builds. This support is added to Maven core, but it requires the plugins used during a parallel build to declare themselves thread safe for it to properly work. If a plugin goal is thread safe (and most of the major goals are by now), this is described on the goal description page of its Maven site.

This feature isn't a match for every build. For example, some types of integration tests might not be suitable for parallel. However, when parallel builds are used, it often results in a much faster build times. Below are two different projects which Dennis did some benchmarking on. The determining factor for performance improvement, aside from the number of CPU cores, was the dependencies between the modules. Project's with wide internal dependency trees experience more build time reductions than those that had very deep dependency trees. The structure of your internal dependencies dictates which builds must be serialized with one another and which builds can be executed in parallel.

More info regarding parallel builds in Maven 3 can be found on this Maven wiki page.

"mvn package" on Maven SCM trunk (32 modules)

"mvn package" on a corporate project (11 modules)

#10. Maven 3 Builds are Faster, Much Faster

Possibly the one reason all of us could agree on is better performance. Maven 3.0 is both faster and has a lower memory footprint than Maven 2.x. While there might be some rare corner case where this isn't true, Maven 3 builds are dramatically faster in almost all cases. How much you gain depends on the structure and content of your project though. For his talk, Dennis had some benchmarks which are shown below. The benchmarks were done on a dual-core CPU and 4GB RAM, running Windows XP with JDK 1.5.

"mvn package" on Maven SCM trunk (32 modules)

"mvn package" on a corporate project (11 modules)

Conclusion

If you haven't already tried Maven 3.0 I strongly recommend you to do so. As a release manager, tech lead, Maven guru, build monkey, or whatever your title is, doing a build of your project with Maven 3.0 will very quickly show you if there are any issues in switching. As installing Maven only requires unpacking a zip file and changing a symbolic link (or environment variable on Windows), it is something you can do in a couple of minutes. Once you've experienced Maven 3, I doubt you want to go back to Maven 2.