The primary source of information for this delta are the compatibility notes and the plugin compatibility matrix.  These documents focus on changes that could negatively affect existing builds due to stricter behavior of Maven 3.0, but we also managed to implement a few general improvements here and there.

The support for parallel builds is one of the major improvements in Maven 3.0, thanks to Kristian. For more on this, visit the wiki page.

The POM’s <build> section allows one to define a <defaultGoal> such that a simple invocation of mvn does something useful with the project, for instance running the install phase. In Maven 2.x, only a single default goal could be specified. With Maven 3.0, you can specify multiple goals, each separated by whitespace like <defaultGoal>clean install site</defaultGoal>.

Note that the <defaultGoal> element still only gives zero or more goals, it cannot be used to specify profiles or other arguments one can pass to the command line. The extended format of the <defaultGoal> element is still compatible with Maven 2.x to a certain degree. Most importantly, a POM having multiple default goals can be successfully consumed by Maven 2.x during dependency resolution. And as long as one doesn’t ask Maven 2.x to run the default goal, it’s even possible to still build such a project with Maven 2.x.

One way to activate a profile is to check for the presence/absence of a file. In Maven 2.x, this can get rather frustrating when trying to use a relative path for the activator because here a relative path is resolved against the user’s current working directory. But what you usually want is to resolve the path against the base directory of the currently built project such that the profile can be defined in a parent POM, and that it still works properly across all modules of a reactor build.  We’re happy to announce that it finally works this way in Maven 3.0.  That is, you can use <missing>src/main/marker.txt</missing> or more explicitly <exists>${basedir}/src/main/marker.txt</exists> to point at files within the project.

It’s worth mentioning that only the expression ${basedir}, and not its close relative ${project.basedir}, is supported for this kind of profile activation. The reasoning behind this subtle restriction is to avoid the erroneous generalization that one could use any expression of the form ${project.} for profile activation. Only system properties, environment variables ${env.} and ${basedir} are valid within the <file> profile activator. Tip: Support for the ${basedir} expression in this context is new to Maven 3.0 so if you have the hopefully rare need to configure plugins differently when building a project with both Maven 2.x and 3.x, you can use the the condition <exists>${basedir</exists>}} to detect Maven 3 and create a dedicated profile.

There’s another improvement regarding profile activation based on properties. So far, profiles could only be activated by system properties. In Maven 3, profiles in the POM can now also be activated from properties specified in active profiles of the settings.xml. In more detail, if your settings.xml contains a snippet like:

<settings>
  ...
  <profiles>
    <profile>
      <id>development</id>
      <properties>
        <someName>someValue</someName>
      </properties>
    </profile>
  </profiles>
  <activeProfiles>
    <activeProfile>development</activeProfile>
  </activeProfiles>
</settings>

The property someName can be used to activate this POM profile:

<project>
  ...
  <profiles>
    <profile>
      <id>test</id>
      <activation>
        <property>
          <name>someName</name>
        </property>
      </activation>
    </profile>
  </profiles>
</project>

In case of conflicts, system properties specified on the command line take precedence over the properties from the settings. As a final clarification, this feature merely allows profiles from the settings to activate profiles in the POM. Profiles within the settings cannot activate each other and profiles in the POM also cannot activate each other.

One of the other major improvements in Maven 3.0 is the resolution of inter-module dependencies from the current reactor build. In the past, it has been quite frustrating for users to find out that mvn install works but mvn verify sometimes fails to resolve artifacts that have just been built by a previous module, in particular when releasing a new version of their projects.

Likewise, it’s hard to understand why an execution of maven-dependency-plugin:copy-dependencies succeeds to resolve artifacts from the reactor while the similar maven-dependency-plugin:copy goals fails. As part of all the refactoring in Maven 3, a dependency resolution has been reworked to consistently check the reactor output. Apparently, the reactor output depends on the lifecycle phases that a project has completed. So if you invoke mvn compile or mvn test on a multi-module project, the loose class files from target/classes and target/test-classes, respectively, are used to create the required class path. As soon as the actual artifact has been assembled which usually happens during the package phase, dependency resolution will use this file. Last but not least, dependencies using version ranges can now be resolved from the reactor, too.

The last improvement to highlight is the improved class loader hierarchy in Maven 3.0. Maintainers of multi-module projects will likely remember the difficulty using different versions of a plugin in different modules. Trying to use the same plugin version but with different project-level plugin dependencies is another yet related pain point in Maven 2.x that basically reuses the same class loader for a given pluginGroupId:pluginArtifactId coordinate.

The end result were builds that succeeded when invoked on a single module but failed within the reactor or vice versa. The maven-antrun-plugin is probably the most common plugin that suffered from this shortcoming of Maven.  With Maven 3.0 users will find that the new release is capable of distinguishing those differences in plugin use such that modules always build the same, regardless whether built in isolation or within a reactor.

Maven 3 offers better stability and performance, but the biggest changes won’t be noticed by users. Under the hood, a great deal of work was done to prepare Maven for a future of building OSGi applications and using dynamic languages to script the build process.

To read the full article, click here.

We have work to do on Tycho to get it fully setup for the parallel IP process at Eclipse, we will soon start a very intensive set of iterations to bring the M2Eclipse core to a 1.0 state, and we have committed within Sonatype to move M2Eclipse to the Eclipse Foundation. The M2Eclipse project at Eclipse has been in suspended animation for a while but we plan to work toward getting M2Eclipse into the release train and have Indigo be the first Eclipse distribution to ship with Maven capabilities. Tycho and M2Eclipse will also be a lot of work, but I think Sonatype has demonstrated that we’re committed to making these projects work and can deliver as we’ve shown with Maven 3.0.

There will be a release fairly soon of the Maven Shell, I will be starting a new phase of work on Polyglot Maven, and I’ll also be talking about concretely what Sonatype plans to do around Hudson — and what we’ve already done. Once we get a few more of the projects we’re working on to a healthy state we will begin the dialog with the community about what features users are looking for in future versions of Maven and related tools.

The Maven community owes a special thanks to Benjamin Bentmann, who has worked consistently and persistently for a long time on Maven 3.0. He has been amazingly responsive in applying fixes for reported issues, and has set the bar very high for the quality of a open source project. We have an enormous number of integration tests and without a doubt, Benjamin really has made this the best version of Maven we’ve ever had. I’d also like to thank Igor Fedorenko who is responsible for Tycho, along with all the changes he made to Maven core to allow its dynamic adaptation, as well as putting in place the performance framework for Maven 3.0. And Maven users can also thank Oliver Lamy for making sure the Maven Site Plugin is compatible with Maven 3.0.

You can download Maven 3.0 now!

http://www.apache.org/dyn/closer.cgi/maven/binaries/apache-maven-3.0-bin.zip

http://www.apache.org/dyn/closer.cgi/maven/binaries/apache-maven-3.0-bin.tar.gz

Enjoy!

We know as the RCs are released more people will be trying Maven 3.x and feedback is critical. We obviously cannot fix your problem if you do not report the problem. Sonatype has two full-time people working on fielding the found issues so this is your chance to make sure Maven 3.0 final works for your projects. Sonatype has made a great deal of effort putting in place unit tests, integration tests, and performance tests for the core and the core plugins, so we’re ready for the feedback and will correct anything we find quickly.

Anyone interested in taking a preview of the upcoming release for a test drive can get source and binary bundles from this URL:

https://repository.apache.org/content/repositories/maven-030/org/apache/maven/apache-maven/3.0-RC1/

Note that this is a staged release and we will keep re-staging while we find serious regressions, but we want to get users into this cycle of testing the RCs as soon as possible. Once we get past anything nasty we will release the final RC1.

Before reporting any issues found during testing, please be sure to have a close look at the compatibility notes for Maven 3.x:

https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes

If you encounter unexpected build issues, please fill a report in JIRA that provides sufficient information to reproduce and analyze the issue:

http://jira.codehaus.org/browse/MNG

The fixes contained in this release candidate since the 3.0-beta-3 release can also be seen in JIRA:

http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=PRIR5ueW-i&version=13142&styleName=Text&projectId=10500&Create=Create

It’s still possible to make our intended Maven 3.0 final release on October 1st, but we need your help!

Thanks!

The June newsletter also previews some upcoming webinars taking place on June 10 and June 24.  These free webinars cover the Developer Onboarding feature of Maven Studio for Eclipse.  Among other features, Maven Studio for Eclipse will get new developers up and running on a project within minutes.  Stop wasting time and money by spending days training developers on new projects.

Sonatype has added some exciting new events to our schedule, including the Maven Meetup and DemoCamp happening June 16 in Guelph, Ontario.  For all of this info and more, check out the latest edition of the Sonatype newsletter.

You can read more here:

 http://maven.apache.org/

Downloads of source and binary distributions are listed in our download section:

 http://maven.apache.org/download.html

A major goal of Maven 3.0 is to be compatible, to the extent possible, with existing plugins and projects designed for Maven 2.x. Users interested in testing this beta release should have a glance at the compatibility notes for known differences between Maven 3.0 and Maven 2.x:

 http://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html

If you encounter unexpected problems while using Maven 3.0-beta-1, please feel free to contact us via the Maven developer list:

 http://maven.apache.org/mail-lists.html

With the switch from Maven 1.x to 2, developers had to manage some fundamental changes. What challenges can users expect when migrating from Maven 2 to Maven 3?

We are planning that, in most cases, Maven 3.0 will be a drop-in replacement for Maven 2.x. We have gone to great lengths to ensure backward compatibility while reimplementing a good portion of Maven’s internals. From the command-line perspective we are trying to be fully compatible. Maven 3.0 will not allow duplicate dependency or plugin declarations, so those problems would need to be fixed, but aside from that no changes to your POMs will be required. In all other regards we have created backward compatibility layers to protect users from the many internal API changes that we have made. I really hope that the Maven community can move forward to Maven 3.0 without grief, and use the new features as it is convenient for them.

Is there anything users should keep in mind when creating a new project, to be prepared for Maven 3?

It honestly shouldn’t be any different from Maven 2.0. That’s the intended goal. So much has changed under the covers that we didn’t want to change the POM format. The primary goal is a path forward for all Maven users, efficient embedding, increased performance, synchronizing the Maven 3.0 code base with m2eclipse, and adding extension points for tools like Tycho, Polyglot Maven, and the Maven Shell.

Will Maven 3 support the integration of dynamic languages (e.g Groovy)?

It would be more accurate to say that Maven 3.x can support dynamic languages. This will not be directly available in the Maven 3.0 release, but support for dynamic languages is available now in Sonatype’s Polyglot Maven project which you can find at http://polyglot.sonatype.org. You also have a question below specifically about Polyglot Maven below so I’ll expand on Polyglot Maven there.

Will there still be a settings.xml or can we expect another method of configuration in Maven 3?

In Maven 3.0 we are again not attempting to change the models that users are accustom to. Internally in Maven 3.1 we will expose a security manager and use the settings.xml implementation as the default implementation, but Sonatype is planning on creating an implementation that interacts with Nexus, our repository manager. In dealing with many large organizations we have found that integrating with in-house security systems and custom implementations is necessary so we will be providing an extension point for this with the security manager.

In Maven 3.1 we will also introduce POM mixins to help make configuration more maintainable and portable. One of the frequent complaints with Maven 2.0 is that sharing configuration can only be done via inheritance. This is obviously problematic as not all projects within organizations, and certainly not all projects in OSS, share lineage. POM mixins are a form of POM composition where a parameterized fragment of a POM can be injected into the current POM with a simple reference.

For me, the first mixin that I wanted to create was a mixin to encapsulate a standard release capability for Maven projects. Apache projects that use Maven inherit the Apache POM, which contains configuration for our release process.  This incorporates license attribution, PGP signing, staging and promotion with Nexus, an Apache compliant source archive containing the original project structure, and the production of the standard source and javadoc JARs. I wanted to create a very easy way for any project to incorporate this capability in their project. The release mixin consists of plugin declarations, their configuration which can be parameterized, and a specification of what POM elements are required in the target POM for the mixin to operate correctly. The POM mixins can then be deployed to a remote Maven repository to be shared via a standard Maven coordinate. In the target POM you specify the coordinate of the POM mixin along with any parameters required by the POM mixing, and Maven will retrieve the POM mixin and inject it into the target POM.

What I expect to see are projects in the community creating mixins for capabilities that require the interaction of many plugins along with the accompanying configuration. One of the biggest problems in Maven, given it’s distributed nature and there being so many plugins, is finding the right plugins that work together and figuring out how to configure a set of plugins to arrive at the desired result. The POM mixins will remove much of this pain.

Can you tell us a bit about Nexus?

I’m going to let Brian Fox, Nexus lead and Maven PMC Chair, answer this one.

Nexus is a repository manager built by the Maven experts at Sonatype. Repository managers serve a few of purposes in an organization: they act as highly configurable caching proxies for remote repositories, and they provide a centralized location to deploy, store, index and share all your internal artifacts. We use the analogy that a repository manager are to binaries what a source control management systems are to sources. In both cases you can use a flat file system but quickly learn that this isn’t scalable.

Nexus is unique among repository managers for several reasons. First, it is designed to be light on resources and heavy on performance. Second, the data is stored in the native repository layout on disk, which ensures that traditional backup and synchronization tools can be used. You don’t need to be a DBA to get access to your artifacts. Third, Nexus supports many repository formats and can convert on the fly between them: Maven 1, Maven 2, OSGI Bundle Repository (OBR), P2, RubyGems. The community is even working on RPM support.

Nexus is the preferred choice for the largest repositories in the community such as Apache, Codehaus, Jboss, Atlassian, Glassfish and many others. It is available in two flavors: an open source version http://nexus.sonatype.org and a professional version that extends the open source version http://www.sonatype.com/products/nexus with commercial add ons, to further manage the binary lifecycle in enterprise organizations.

In the Maven Repository, there are all kinds of plug-ins, ranging from early Alpha-Versions to stable plug-ins. Do you have any plans for bringing order to this “plug-in chaos”? One could imagine a similar process to Eclipse, with Incubators and a Simultaneous Release Train providing reliable, high quality plug-ins…..

This is something that Sonatype plans to tackle in the near future where we provide a higher quality set of plugins. Maven, by it’s distributed nature, makes it pretty hard for us to guarantee the quality of Maven plug-ins in every Maven repository around the world and what ultimately lands in Maven Central. But what we can do is “battle test” a smaller set of plug-ins and make sure they have integration tests, perform well, and integrate properly with m2eclipse. Once Maven 3.0, m2eclipse 1.0, and Tycho 1.0 are released we plan to start this project.

Sonatype have just released version 0.10.0 of their m2eclipse Maven Plug-in for Eclipse. What new features does 0.10.0 have to offer? And will version 1.0 bring major changes?

m2eclipse 0.10.0 is almost a complete rewrite from 0.9.8 so there are many changes and improvements. The most important aspect is that we have the m2eclipse code base synchronized with the Maven 3.x code base. When we need fixes in m2eclipse that are the result of problems in Maven, it’s only a matter of hours before we can roll a fix through the system and produce a new m2eclipse build. There have been several hundred fixes across Maven and m2eclipse in the last year. We’ve probably put in close to eight thousand man hours across Maven and m2eclipse as we approach the Maven 3.0 and m2eclipse 1.0 releases.

The performance will be the first thing users notice. Even with a standard Maven project general operation is faster, but if you leverage the new incremental Maven Plugin API and the customizable lifecycle mapping you truly have incremental behavior with Maven inside of Eclipse.

The new incremental Maven Plugin APIs allow Eclipse to communicate very precise information back to Maven. For example, if you change a single resource that needs to be filtered, Eclipse will no longer trigger Maven’s entire lifecycle, but rather communicate the information about the single file that has changed and execute Maven’s resource plugin to operate on the single file that changed. The customizable lifecycle mapping allows m2eclipse to eliminate most of Maven’s execution from within Eclipse. You can selectively choose what plugins you want to execute as part of the build within Eclipse. The end result is that if you tune your project, you can get extremely fast results. We want to make this tuning easier as we move toward the 1.0, but it’s still relatively easy to do this today.

We also have improved integration with Nexus so you can search the content of your repositories from within Eclipse, and we have simplified the configuration of repository indexes by automatically configuring them based on repositories you have configured in your settings.xml file.

There’s already an official Eclipse project for integrating Maven: IAM (formerly ‘Q4E’). What’s the difference between m2eclipse and IAM? And is a merger of the two projects conceivable?

IAM is not the official project for integrating Maven. Both m2eclipse and IAM are in incubation, so neither has official status at Eclipse. It’s unlikely there will be a merger. The IAM code base is a year behind m2eclipse at this point, and there are no active Maven 3.x committers on the IAM team. Sonatype has full-time developers and QA staff on Maven 3.x and m2eclipse. We’ve done a lot of work over the last year to make sure Maven and Eclipse work well together. m2eclipse is the de facto standard. You can see this in the community as questions on the user mailing lists are always about m2eclipse, and vendor support is already in place for m2eclipse – Genuitec, JBoss, and SpringSource all integrate m2eclipse, not IAM. Eclipse may ultimately let both projects graduate from incubation, but only one project will be official and shipped with distributions, and it very likely that will be m2eclipse. It simply boils down to manpower. We always hope for community support, but at any given time Sonatype has up to eight full-time people working on m2eclipse so users can be assured bugs will be fixed and new features will be developed.

Can you tell us a bit about the P2 project at Eclipse and how Sonatype has become involved with the P2 project.

The P2 project at Eclipse is the basis of the update manager in Eclipse, but it is also a general purpose provisioning framework. Sonatype is interested in provisioning user desktops, provisioning development infrastructures, and provisioning production run-times. P2 has become a critical technology for Sonatype, so we recently hired Pascal Rapicault who is the lead of the P2 project at Eclipse. Pascal will remain heavily involved in the community, in much the same way that Sonatype is heavily involved in the Maven community. We are also planning to invest in some research and collaborate with Daniel Le Berre through the National Centre for Scientific Research in France. Daniel is the creator of SAT4J, which is the core solver used in P2 for determining the selection of dependencies. I am interested in trying to merge the artifact resolution strategies of Maven and P2.

Maven Tycho is your new OSGi-Toolchain designed to be a drop-in replacement for the Eclipse PDE Build. What are the goals of the Tycho project? And what features are already available?

The focus of Tycho is to create an effective hybrid of Maven and Eclipse-based OSGi technologies for building, publishing, and distributing Eclipse plugins, update sites, RCP applications and OSGi bundles. Tycho is a manifest-first approach to building and leverages Eclipse’s Equinox, JDT and P2 projects. The alternate approach is a POM-first approach which is the strategy employed by the Maven Bundle Plugin which uses Peter Krien’s BND tool to generate a manifest from the classes post build.

Both of these approaches will be with us for quite a while, so another goal of Tycho is to allow these different approaches to interoperate. Both approaches produce bundles, but in order to use Tycho the bundles must be available in a P2 repository and have the accompanying P2 metadata. So with a POM-first approach we dynamically generate the required P2 metadata for bundles that do not have it. This effectively allows us to take all bundles available in Maven Central and allow them to be used within Tycho. I believe that an unmanageable rift will form if tools are not capable of interoperability between these two common forms of development. Many people use Maven only to produce bundles, and many people use standard Eclipse-based technologies to produce bundles, and if these worlds are not united there will be a massive duplication of effort. Tycho is a bridge between these two worlds.

We have also integrated Tycho with m2eclipse so that you can import a Tycho project into Eclipse as a PDE project. We have also added support to allow the resolution of POM-first bundles in the Eclipse workspace. Currently there are two major projects at Eclipse that are using Tycho to build: the Tigerstripe project driven by Cisco, and the EGit project. The EGit project is interesting because it uses the hybrid approach of using a POM-first build for JGit, we then generate a P2 repository from the Tycho build which is then consumed by the EGit build which uses a manifest-first Tycho build.

Can you tell us a bit about Polyglot Maven?

Polyglot Maven is the project for experimenting with domain specific lanaguages (DSLs) and terse markup languages (TSLs) in conjuction with Maven 3.x’s core. What is currently available today can be found http://polyglot.sonatype.org. What we have are starting points of internal DSLs for Groovy, Ruby, Scala, and Clojure. There is also an external DSL that I have developed using XText, which is a fantastic tool at Eclipse.org for creating parsers and editors for external DSLs.  We are also providing support for YAML-based POMs using the excellent SnakeYAML library.

The DSLs are meant to be more then merely different representations of the POM. The DSLs will have full access to Maven’s internals, which have been redesigned for integration and extension. What this means in practical terms is that implementors of DSLs can leverage Maven’s infrastructure but create custom ways to interact with, or extend, Maven. A DSL could change Maven’s lifecycle, decorate lifecycle phases, create new configuration mechanisms, or allow a more procedural mechanism for their users. I honestly don’t know how useful these features are for general users, and more specifically enterprise users, but I only see benefits in allowing greater leverage of Maven’s infrastructure.

What I really care about and what really concerns me is interoperability at the repository level and tooling. This is why the code lives in the Polyglot Maven project. I don’t want to misrepresent to users that this is ready for prime time. It fully works, but there needs to be more thought about how projects being constructed with possibly many DSLs can still play nicely together. What will the resultant metadata look like that is exported to Maven repositories? Currently we feel that this is likely to be a Maven 2.x POM created during the deployment process. What will the tooling look like for Maven DSLs? We are hoping that the DSLs can preserve many of Maven’s internal models so that they can leverage m2eclipse. To simply provide the infrastructure for these DSLs is not enough; repository interoperability and tooling is important.

In the last 18 months I have surveyed nearly 2000 people from the various talks and presentation I’ve given, and approximately 5% of the people surveyed are interested in DSLs for Maven or different representations of the POM. But these 5% are very important. These are the very creative hackers that want to do things in a project from one end to the other in a fully programmatic way. They want to code everything including the build. This is why I created Polyglot Maven because I believe this 5% can potentially contribute as much to Maven as the remaining 95% of the Maven user base. The folks who want the polyglot support are highly effective people. In the end it’s all good for Maven.

Can you tell us a bit about the Maven Shell?

The Maven Shell is Maven embedded in a long-lived shell process. The shell avoids the start-up costs of invoking Maven repeatedly, caches the parsed POMs, provides Maven Archetype integration, provides Nexus integration, has a built in help system, and on the OS X provides Growl support. In typical cases you’ll see your build times cut in half. We have many features planned for the 1.0, such as the integration of the make-like reactor mode so that within the shell only the modules that have changed will be built, project workflow support to help guide users do the right thing, Hudson support for creating jobs and querying statuses, and ultimately the integration of Tycho and Polyglot Maven features.

There are many different build systems to choose from. In your opinion, which is Maven’s biggest competitor? Maybe Gradle…..?

Maven’s biggest competitor in the enterprise are homegrown Maven-like solutions created with Ant. These are the systems that Maven typically replaces in enterprise settings. We honestly don’t see anyone trying things like Gradle or Buildr for large enterprise projects. I think there is a lot of hype around some of these technologies. We understand that people are constantly looking for new solutions, but we’re also convinced that the enterprise build space is full of complicating factors that don’t lend themselves to over-simplification.

In three sentences: Why should we switch to Maven 3?

Maven 3.0 will be the best version of Maven ever made. We are doing everything in our power to make it backward compatible and we have put in thousands of man hours in testing and performance tuning. Maven 3.0 is the future of Maven and the path forward for all users who wish to use new technologies like m2eclipse, Tycho, the Maven Shell, Polyglot Maven, and Nexus.

And is there a release date?

We are planning for the Maven 3.0-beta-1 around the beginning of April, and based on feedback and good weather permitting we will release Maven 3.0 at the beginning of May.