The Apache Maven team announced a while ago to stop supporting Maven2.
Now it is time for the plugins to follow. This pages describes the topics on what to do to make plugin Maven3+ compliant.
- Set the Maven prerequisite and dependencies to 3.0, which might cause one or more of the following issues:
- Set both the
maven.compiler.targetproperties to 1.6
- If the project depends on maven-plugin-testing-harness, use version 2.1, since newer versions depend on newer version of Maven dependencies. Ensure to exclude the maven-2.x dependencies which don't exist anymore, e.g. maven-project
- Remove maven-compat (or give it the test-scope if it is required by the maven-plugin-testing-harness)
Maven compat mainly contains business logic which has been moved to Aether. However, we need to support the implementations of both Sonatype (M3.0.x) and Eclipse (M3.1+). The shared component maven-artifact-transfer can select the proper implementation.
- Transitive dependencies may still refer to Maven-2.x artifacts, even if they don't exist for Maven 3.x any more: ensure these are excluded. You can enforce this by adding the requireSameVersions enforcer rule to your project.
- Reporting plugins should include org.apache.maven.reporting:maven-reporting-api:3.0
The following plugins already use successfully without maven-compat and with maven-artifact-transfer:
- maven-assembly-plugin (in trunk, with maven-compat in test scope)
- maven-dependency-plugin (trunk)
- maven-deploy-plugin ( https://svn.apache.org/repos/asf/maven/plugins/branches/m-deploy-p-3.0 )
- maven-install-plugin ( https://svn.apache.org/repos/asf/maven/plugins/branches/m-install-p-3.0 )
- maven-invoker-plugin ( https://svn.apache.org/repos/asf/maven/plugins/branches/m-invoker-p-3.0 )
- maven-shade-plugin ( https://svn.apache.org/repos/asf/maven/plugins/branches/m-shade-p-3.0 )
Maven Shared Components needed to be upgraded:
- maven-shared-utils (3.0.0)
- maven-archiver (3.0.0)
- maven-filtering (3.0.0)
- maven-jarsigner (3.0.0)...(maven-shared-uitls )
- maven-common-artifact-filters (maven-shared-utils )..
- maven-mapping (3.0.0)
- maven-artifact-transfer (3.0.0) (maven-common-artifact-filters ).
- maven-shared-io (3.0.0)
- file-management (3.0.0) (maven-shared-io )
- maven-repository-builder (maven-shared-utils maven-common-artifact-filters )
- more of them?
Known plugins still to do (there are probably more):
- maven-ejb-plugin (uses maven-archiver , maven-filtering )
- maven-rar-plugin (uses maven-archiver , maven-filtering )
- maven-resources-plugin (uses maven-filtering )
- maven-war-plugin (maven-archiver 3.0.0 , maven-filtering 3.0.0 , maven-mapping 3.0.0 )...
- maven-ear-plugin (maven-archiver 3.0.0 , maven-filtering 3.0.0 )...
- maven-jarsigner-plugin (maven-shared-uitls 3.0.0 , maven-jarsigner 3.0.0)..
- maven-assembly-plugin (maven-archiver maven-filtering , maven-common-artifacts-filter maven-repository-builder , maven-shared-io , file-management , )
- maven-verifier-plugin (works so far so good. JUnit should be updated)...
- more of them?
The plugins which have been lifted to 3.0.0‚
- maven-clean-plugin (has been released as 3.0.0).
- maven-acr-plugin (has been release as 3.0.0).
- maven-source-plugin (has been released as 3.0.0).
- Rename package to
org.apache.maven.plugins.xxx (matching the groupId, not conflicting with maven-core
- Resolve reflection usage, meant to call Maven3 specific code when available.
- Remove deprecated parameters, methods, goals, classes
- Remove unnecessary overloaded methods. Some methods have been extended with arguments to stay backwards compatible. Time to clean this up (if the number of arguments is still uncertain, use a Request/Result object containing the argument objects, so the method signature will stay the same).
Stuff that may have changed
Testcases with this code:
container = new DefaultPlexusContainer();
container.initialize(); // This statement can be removed for 3.0
container.start(); // This statement can be removed for 3.0
Intermittently (and while upgrading) you may find code like this:
metadataSource = (ArtifactMetadataSource) lookup( ArtifactMetadataSource.ROLE );
While you are still working with maven-compat, you can fix this by switching to lookup by type;
metadataSource = (ArtifactMetadataSource) lookup( ArtifactMetadataSource.class);
Some adaptions necessary, some reflection to stay compatible with 2 Aether versions. See http://svn.apache.org/viewvc?view=revision&revision=r1685177 for sample
org.apache.maven.repository.RepositorySystem (however, there's only one implementation: LegacyRepositorySystem,
which is again part of maven-compat AND reuses ArtifactFactory)
Depending on what you want to do next with the Artifact, you could use TransferUtils.toArtifactCoordinate() instead.
Improved separation of dependencies and artifacts
It won't be possible any more to get the dependencies based on an artifact, since an artifact is basically a reference to a file with a coordinate. Instead you must use a dependency, plugin, extension or other model entity to resolve the dependencies. See http://maven.apache.org/shared-archives/maven-artifact-transfer-LATEST/comparison.html for a matrix.