Page History

...

The support for profiles outside of the POM or the settings.xml has been removed in version 3.x and users that previously used this feature are advised to move the affected profiles into their settings.xml.

Non-unique Snapshot Deployments

The setting <uniqueVersion>false</uniqueVersion> for a distribution repository has no effect in version 3.x, snapshot artifacts will always be deployed using a timestamped version.

Site and Reporting

A major aim of the refactoring in Maven 3.x was to decouple the Maven core from Doxia and to allow arbitrary reporting systems to be developed. For this reason, all reporting related code has been removed from the core of Maven 3. As a result, the 2.x versions of the Maven Site Plugin will no longer work with Maven 3. Development of an updated version of the Maven Site Plugin has already been started. See Maven 3.x and Site Plugin for further information.

In the same context, the default execution of site:attach-descriptor has been removed from the built-in lifecycle bindings for projects with packaging "pom". Users that actually use those projects to provide a common site descriptor for sub modules will need to explicitly define the following goal execution to restore the intended behavior:

  ...
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-site-plugin</artifactId>
        <version>2<version>3.0.1<-beta-2</version>
        <executions>
          <execution>
            <id>attach-descriptor</id>
            <goals>
              <goal>attach-descriptor</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
  ...

...

Maven 3.x no longer supports repositories using <layout>legacy</layout>. Users that need to access repositories created with Maven 1.x are advised to use a repository manager that is capable of providing a Maven 2.x compatible view of the legacy repository.

Caching of Artifact Resolution Errors

To improve network performance, Maven 3 remembers when an artfifact could not be resolved (by means of a marker file in the local repository). This cache expires according to the update policy of the respective repository and gets automatically cleared when the repository URL etc. changes. In some situations, e.g. when a repository manager is used and its configuration gets changed to proxy another repository, users might need to manually invalidate the cache by adding the flag -U to the command line, thereby forcing Maven to update the artifact status and retry to resolve it.

Snapshot Updates

Due to implementation differences, Maven 3 and Maven 2 use different files in the local repository to track metadata. For users that employ Maven 2 and Maven 3 (or integrators of Maven 3 like M2Eclipse) side by side on the same projects, this causes both Maven versions to independently check for updates of snapshot artifacts. In other words, even if one Maven version just checked for snapshot updates, the other Maven version will do again.

Non-unique Snapshot Deployments

The setting <uniqueVersion>false</uniqueVersion> for a distribution repository has no effect in version 3.x, snapshot artifacts will always be deployed using a timestamped version.

Unique Snapshot Versions and Classifiers

As described in MNG-4452, Maven 3 now supports deploying artifacts with different classifiers from a different build or source and having them properly resolved.

This may impact Maven 2 or other clients that use the repository metadata to determine the version, since the version of the POM would be out of sync with the latest version of some artifacts. While this behavior matches the result of attempting to do the same in Maven 2, please be aware that you will not be able to successfully make subsequent deployments from Maven 3 if you have Maven 2 clients accessing the repository.

Additionally, some repository managers and versions of Maven prior to 2.0.10 may not cope with the additional XML elements in the metadata file. If this is the case in your environment, you can disable the additional information by setting the maven.metadata.legacy system property to true when running Maven.

Automatic Plugin Version Resolution

...

Maven 3 aims at supporting a stricter separation between the compile/runtime/test dependencies of a project and the plugins used to build the project. For this reason, both build extensions, plugins and build extensions plugin dependencies are no longer resolved from the <repositories> of a project but only from its <pluginRepositories>.For clarity, this rule only applies to the resolution of the root artifact. In other words, while a plugin is only resolved from a <pluginRepository>, the dependencies of the plugin are resolved from the original <pluginRepository> and any <repositories> specified in the plugin's POM

Resolution from Local Repository

The local repository used by Maven 3.x has been enhanced to keep track from what remote repositories an artifact was resolved from. This information about an artifact's origin is used to ensure builds can only access locally cached artifacts if they have the proper repositories configured. Hence, projects that lack required remote repositories in their POM might fail when being built with Maven 3. This improves reproducibility of a build by eliminating the effects of unintended artifact sharing via the local repository.

Dependency Resolution

The core of Maven 3 uses Aether for dependency resolution. Aether employs a different approach to calculate the transitive dependencies and is meant to fix some of the trickier (conflict) resolution issues within Maven 2.x.

In practice, this change can result in different class paths especially for projects with big/complex dependency graphs. For instance, projects that erroneously have conflicting dependencies on their classpath might encounter build issues depending on the classpath order. See JETTY-1257 for a concrete example of this issue.

Furthermore, not all parts of the Maven 2.x resolution API could be bridged onto Aether. Most notably the maven-dependency-tree shared component which is used for mvn dependency:tree still uses the legacy resolution code. As such, the output from mvn dependency:tree can differ from the actual dependency tree used by Maven itself to derive the classpaths of a project (see MSHARED-167 for an example of such a discrepancy). For now, the actual dependency trees can be inspected when running Maven with debug logging enabled.

Last but not least, Maven 3 inspects the POMs of all matching versions when processing version ranges to enable sophisticated conflict resolution.

Version Comparison

Maven 3 incorporates a revised version comparison logic to address some anomalies found with the version ordering in Maven 2.x, e.g. Maven 3 considers 1.0-alpha-1 < 1.0-beta-1 < 1.0-SNAPSHOT < 1.0. This can affect builds using version ranges that previously relied on the corner cases.

Legacy-style Reactor Mode using Includes/Excludes

...

Maven 3 no longer resolves parent POMs from the local project checkout unless the child POM's <relativePath> element is properly specified in the child POMaccurate, whether explicitly given or using the default value. This improves consistency regarding the build result when building the child project in isolation and when peforming performing a reactor build that includes the parent project. In Maven 2, building the child project in isolation could fail while the reactor build would succeed to resolve the parent.

...

Unlike Maven 2, Maven 3 supports out of the box only http:, https: and file: as transport protocols. To use other transport protocols like scp:, the appropriate wagons have to be explicitly declared in the POM as a build extension. If the wagon in question is only used for deployment to a repository, it can alternatively be declared as a dependency of the Maven Deploy Plugin.

Plugin Compatibility Matrix

The table below indicates which plugins are affected by the API changes in Maven 3.x and might not function properly. Please note that the table is not complete, e.g. not all versions of a particular plugin were tested but usually only the latest release version. Also, these results were derived from the integration tests of the plugins, features of the plugin that are not covered by tests are of unknown status.

Symbol Legend:
No known incompatibilities
Some incompatibilities
Incompatible
Not tested

Plugins Maintained by the Apache Maven Community

Plugins Maintained by the Mojo Community

Plugin	Version	Status	Comments
ANTLR-3 Maven Plugin	1.0
Application Assembler Maven Plugin	1.0
APT Maven Plugin	1.0-alpha-3		Plugin versions before 1.0-alpha-3 employ a hack for embedded invocation of APT which no longer works with the class loader hierarchy in Maven 3 (MOJO-1458). Users that can't update to a newer version of the plugin can use the configuration <fork>true</fork> to workaround the issue.
Axis Tools Maven Plugin	1.3
Build Number Maven Plugin	1.0-beta-3
Failsafe Maven Plugin	2.4.3-alpha-1
Findbugs Maven Plugin	2.3		Plugin versions before 2.3 are coded against implementation classes rather than interfaces but the underlying implementation of the API has changed in Maven 3 which causes linkage errors (MFINDBUGS-100).
GWT Maven Plugin	1.2		Plugin versions before 1.2 use internal types that are no longer present to locate sources for projects in a reactor build.
Hibernate3 Maven Plugin	2.2
JavaCC Maven Plugin	2.5
JavaNCSS Maven Plugin	2.0
JBoss Packaging Maven Plugin	2.1
JSPC Maven Plugin	2.0-alpha-3
OpenJPA Maven Plugin	1.0
Selenium Maven Plugin	1.0		This plugin depends on the GMaven runtime which is not compatible with the updated IoC container in Maven 3.
Tomcat Maven Plugin	1.0-beta-1
Versions Maven Plugin	1.0
XDoclet Maven Plugin	1.0
Sonar Maven Plugin	1.0-beta-1		http://jira.codehaus.org/browse/SONAR-1265Image Removed

Plugins Maintained by Third Parties

...

Plugin

...

Version

...

Status

...

Comments

...

YUI Compressor Maven Plugin

...

0.7.1

...

...

The plugin has an undeclared dependency which causes it to fail due a linkage error. Until the plugin itself gets fixed, users can simply add the missing dependency org.codehaus.plexus:plexus-utils:1.1 to the <dependencies> of the <plugin> declaration.

For more information, see Guide to Using Extensions.

Error Reporting

Maven now always shows a reactor summary when an error occurs, then follows with an explanation based on the exception that occurred. If your plugin relies on reporting errors that are not included in the MojoFailureException or MojoExecutionException (eg through the logger), these may not be as visible to your users. Sufficient detail (or encouragement to scrollback) should be included in the exception message.

Plugin Compatibility Matrix

The Maven 3.x Plugin Compatibility Matrix lists known issues regarding the usage of existing plugins with Maven 3.x. Please consult this table before filling an issue in our issue tracker

...

Tobago Maven APT Plugin

...

1.0.23

...

...

.