Maven 3's revamped internals support more efficient embedding. Hudson and Sonatype's multi-year investment in bringing both JSR-330 support and GWT UI integration to Hudson CI has resulted in a continuous integration platform that supports Maven 3 particularly well.
To ensure that Hudson users have the flexibility they need to create quality enterprise builds, Sonatype has taken Maven 3 support in a new direction. In a complex build environment, Maven is often not the only build tool involved in a process. So instead of binding users to a single Maven-specific project type, there is a Maven builder that can be used as part of a larger freestyle build. Maven 3 build processes can contain two separate calls to release:prepare and release:perform to better support real-world Maven builds that need to prepare and perform releases. Developers can also call out to supporting scripts or other build parts that fall outside of the scope of a Maven build.
Fixes to Maven 2
Today, focus has shifted to Maven 3 and few committers are paying attention to Maven 2. While Maven 2.x defects do eventually get fixed, there is no longer a sustained effort to test and push new Maven 2 releases. In contrast, Maven 3 has a six-week release cycle.
Maven 3 has improved artifact/dependency resolution. Previous artifact resolution deficiencies in reactor builds (that is, builds in which a goal is executed on a specific set of modules) led to problems when Maven 2.x users tried to build multi-module projects unless they executed "mvn install." This was caused by the fact that artifacts built by the modules were not resolved properly from the reactor. This defect led to an extra step of configuring the preparationGoals parameter of a maven-release-plugin to "clean install" instead of the default "clean verify." Maven 3 corrects this problem and resolves artifacts within the reactor, which allows you to use the default values of the preparationGoals parameter to streamline the build process.
Maven 3 also responds directly to the request to provide more intelligent class loading for multi-module builds. In Maven 2, the first execution of a plugin determined the classpath for all subsequent executions of that plugin. This often led to complications when a plugin required the use of a different classpath in its second invocation during a build. For example, Maven 2 users who needed to execute the Antrun plugin more than once in a multi-module build with two different classpaths were simply out of luck. This issue was fixed in Maven 3 by making sure that every execution gets its own, isolated classpath.
Interestingly, the Maven 3 codebase is two-thirds the size of the Maven 2 codebase. This is due in part to Maven 3’s use of Google Guice for dependency injection and Sisu to extend Guice’s OSGi capabilities. This release moves the entire dependency resolution mechanism into a standalone product, Sonatype Aether, for which Maven 3 is a client.
Maven 3 is continuously evolving and is currently at version 3.03. Looking ahead, Maven 3.1 will include a security manager with the settings.xml file specifying the default. Maven 3.1 will also introduce POM mixins, which are a type of POM composition that enables parameterized POM fragments to be injected into the current POM with a simple reference. POM mixins make configuration more portable and maintainable, solving the Maven 2 problem where sharing configuration could only be done via inheritance.
Maven 3 is an Apache project and can be downloaded as open-source software http://maven.apache.org">here.
Jason van Zyl is CTO and Founder of Sonatype, and the founder of the Apache Maven project, the Plexus IoC framework, and the Apache Velocity project. He goes by @jvanzyl on Twitter.