Today we are talking with Benjamin Bentmann, a core contributor to the Maven project. Two years ago Benjamin got involved in the project. He helped maintaining various plugins before switching his focus to cleaning up integration tests for the Maven core for about a year. This work has taught him a lot about Maven internals, and soon he was contributing to the Maven core, especially the 3.x branch.
For the past few months Benjamin has been working on the development of Maven 3 full-time, contributing the majority of commits to the code base. He is using this opportunity to take Jason van Zyl's vision, the feedback from early adopters, and from the discussions on the developer list to create a better version of Maven.
Q. What will be the main changes in Maven 3.0 over the previous version, and how will they help Maven users?
To a large degree, the work on Maven 3 is focused on refactoring and cleanup of the code base. This might not be of direct interest to users, but in the medium to long term, refactoring will help us solve some of the trickier issues that Maven 2 has.
To give some concrete examples, artifact handling in Maven 2 has severe problems with version ranges and conflict resolution. To address those issues, a new subproject called Mercury was developed. Early attempts to plug Mercury into Maven 3 failed because the old artifact resolution code was almost omnipresent and not easily replaced. This is why we needed to create a kind of facade first, which would allow us to flip the underlying implementation without breaking any of the existing plugins.
Another major design goal is to allow efficient embedding of Maven into IDEs or CI servers. Increased productivity will be the main benefit of having proper and fast integration of their Maven-managed projects in the IDE. Maven 2 wasn't really up to this requirement as some of its major components were stateful singletons that prohibited use in multi-threaded environments.
Outside of the IDE, the most notable improvement would likely be the changes to handling of multi-module projects during a reactor build. In principle, running "mvn package" should allow inter-module dependencies to be resolved from the outputs of the current reactor build. There are however certain scenarios where this fails in Maven 2, which caused quite some frustration among users in the past. In Maven 3, it's now possible to even run earlier lifecycle phases like "compile" or "test" and have inter-module dependencies reliably resolved from the reactor.
Another noteworthy improvement is the proper isolation of plugins and build extensions in a reactor build. A buggy cache in Maven 2.x reuses plugins and especially their class loaders for different modules in a reactor build, regardless of whether those modules require different dependencies for the plugin. Likewise, build extensions from all modules are aggregated in a single class loader, giving rise to class conflicts. Both of these issues can make multi-module projects with several dozens of modules a pain to manage. Maven 3 keeps the plugins/extensions from different modules separated, thereby ensuring that a module builds the same regardless whether it's part of a reactor build or just built on its own.
2. What about backward compatibility with Maven 2.x?
Our overall aim is to make Maven 3 a smooth upgrade from 2.x. We are working hard to ensure that existing plugins and the projects that use them work the same with Maven 3. For this reason, I spent the last few weeks tracking down regressions, extending our suite of currently over 450 integration tests and restoring backward compatibility where needed.
Still, there are some intentional changes in Maven 3 that can affect existing builds. For instance, Maven 3 performs stricter validation of the POM. One particular issue I have seen several times are duplicate declarations of the same dependency within a POM. Maven 2 silently ignores that, leaving questions like effective class path order open for speculation. Maven 3 will no longer tolerate this. Also, Maven 3 will print out a warning when plugin declarations in the POM have no version provided by means of inheritance or plugin management. History has shown us that automatic plugin version resolution contradicts the reproducibility of a build so we are seeking to ultimately require plugin versions in the POM for future Maven versions.
Another major change is the complete extraction of site/reporting from the Maven core. Maven 3 will no longer be coupled to a single reporting system like Doxia but will instead provide hooks that arbitrary implementations can employ to generate reports. The bottom line is however, that none of the currently released versions of the Maven Site Plugin work with Maven 3. Maven community is already working on a new version of the plugin to close this gap. Let me clarify that existing reporting plugins don't need to be changed, and it is really only the Site Plugin as the orchestrator of the report generation that needs to be updated.
There are other changes that users might want to look at before upgrading and so I filtered the relevant changes into our wiki:
http://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes
This document is a work-in-progress and is frequently updated as we continue work on Maven 3, but it should be good for a first impression.
3. What are you and the rest of the team working on right now?
It seems Maven 3 has reached feature parity with Maven 2 by now so we can expect another alpha soon that users can take for a test drive and help us find any outstanding regressions that we didn't spot so far. I know that the term "alpha" is probably discouraging to users but let me point out that whoever uses the latest developer builds of M2Eclipse is already using Maven 3.
There's still some refactoring and API cleanup to be done before we can call this 3.0 and thereby lock the new APIs down. But apart from this, I think we're getting fairly close to a release.
