Sonatype today announced the release of Maven 3 (release notes), the biggest change since Maven 2 was released in 2005. Unlike the change from Maven 1 to Maven 2, which had changes to the POM as well and caused a significant impact to the Maven community (not the least was the ejection of the Jelly scripting language in favour of Java MOJOs), the release of Maven 3 has been backed up by significant automated testing using open-source projects in the field to try and prevent backward incompatibilities. As a result, Maven 3 should just be a drop-in replacement for Maven 2, with few noticeable differences other than an increase in performance. Any known problems are listed on the compatibility page.
The new version of Maven 3 is built upon Google Guice, a light-weight dependency injection framework, rather than the Plexus container that was solely used before. This refactoring allows other containers to be used in the future, such as Pico Container. The abstraction layer is provided by Sisu, which will also compatible with Spring.
The reporting aspects of Maven have been changed; the dedicated reporting section is now found in a per-report configuration options (similar to plugins). For existing Maven POMs, automatic translation will take care of re-writing, but as Maven 3 becomes widespread, the use of a standalone reporting tag will fade away. In addition, the processing of reports (and site generation) has had to be revamped for Maven 3, and in previous betas, there were some limitations on what the site generation will publish; see the release notes for more details.
Maven Shell
Maven 3 introduces the concept of a Maven Shell, a standalone Java process that is part Maven build, part build server. Maven Shell will load and parse all the necessary POMs for the project, and keep them in memory for faster builds subsequently. In future, this may mean faster builds available for build servers that repeatedly build the same code. The source code is available from GitHub if you'd like to see the code; there's also a FAQ available. Maven Shell will be the replacement of the older maven-cli-plugin, and in future will have built-in support for Hudson, Nexus, JIRA and Confluence .
Tycho and M2Eclipse
As well as improvements to the runtime, Maven 3 also permits other extensions that were not possible in Maven 2. Tycho is a build plugin which allows Maven to build Eclipse plugins, Eclipse features, Eclipse (P2) update sites and Eclipse RCP applications. Not only that, but it can also consume other P2 update sites for those libraries which aren't available in standard Maven repository formats. Several Eclipse projects now use Tycho over the antiquated Eclipse PDE/Ant build, with one saying “Probably the hardest thing about using Maven and Tycho to build my Eclipse project was getting my brain around how easy it is” – anyone who has created an Eclipse build in the past knows how fragile it can be getting it working in the first place, with a “don't touch it!” attitude once it finally does start working. Currently, Tycho is hosted by Sonatype, but will be moving to the Tycho project at Eclipse.org in the future.
The plugin which manages Maven builds inside Eclipse, M2Eclipse, has been updated to use Maven 3.0 with Guice and Aether as well. This provides a simple way of building and managing projects that use Maven. If you've used Maven in the past, then one thing to watch out for is a difference between the maven instance pointed to by M2_HOME and Eclipse, since M2Eclipse will install its own copy of Maven. Currently, M2Eclipse is hosted at Sonatype, but it is being moved to the M2E project at Eclipse.org in the future.
The future
Maven 3 opens a number of possibilities for the future. The format of the POM has been decoupled with the internal data structures, which means it's potentially possible to use other (non-XML) formats. Although not released as part of Maven 3, experiments into Polyglot Maven show this to be a future avenue for development.
Another advantage to the separation of concerns is the ability for POMs to be split over more than one file. This permits “POM Mixins”, a feature which won't be immediately available in Maven 3 but which has already been partially developed. A POM mixin will allow a sub-set of plugins and reports to be defined – somewhat similar to a parent POM, but a standalone entity in its own right which can be applied to multiple projects (which may not otherwise have a common ancestor). Companies and open-source organisations wanting to achieve a degree of uniformity between projects will be able to use the mixin approach to configure standard builds without having to organise them hierarchically.
Finally, the Maven 3.x tree will be moving towards an OSGi runtime after the 3.0 release. This will be enabled by using Peaberry to wire in the dependency injection hooks. One of the big challenges here will be the migration to using OSGi-like versioning schemes (explained at the Semantic Versioning site). Migrating to the OSGi runtime will likely not be a challenging process; however, minor differences between the way that OSGi and Maven treats versions are likely to be more problematic (the unqualified version is 'bottom' in the OSGi range but 'top' in the Maven range), as will symbolic references like SNAPSHOT. Other symbolic references, like LATEST and RELEASE can't be used any more.
A lot of hard work has been done by Sonatype and others bringing Maven 3 to a successful release. You can download it now from maven.apache.org.