Duplicate plugin declaration

A plugin must only be declared once. Defining it multiple times results the following log message.

‘build.plugins.plugin.(groupId:artifactId)’ must be unique but found duplicate declaration of plugin [plugin-name] …

To fix this, remove the duplicated configuration.

Install / deploy at end of build (breaking change)

Both, the Maven Install Plugin and the Maven Deploy Plugin, have changed default values for their behavior, about when to install respectively deploy. The default values for installAtEnd and deployAtEnd are set to true in Maven 4. They now reflect the desired behavior for the majority of the Maven builds. If you manually set these values to true before, you can remove the explicit declaration and inherit the same behavior from the new default values now.

If your build relies on the old default value (false), you have to add it to your plugin configuration now. But in most cases, a build that requires the values to be false means that these settings hide a configuration error. We suggest to analyse the build configuration after migration.

Define project's root directory

It is highly recommended to define the project's root directory. While the definition is not enforced with Maven 4.0.0, it might be in the future. Some new Maven 4 features, for example the ${project.rootDirectory}property, do require it.

When the root directory is not defined, the following warning is displayed:

[WARNING] Unable to find the root directory. Create a .mvn directory in the root directory or add the root=“true” attribute on the root project's model to identify it.

As written in the warning there are two ways to define the root directory:

1. Create a .mvn directory in the root directory. From Maven's perspective, the directory can be empty, but some version control systems do not check in an empty directory. Therefore, placing an empty file inside (or a Maven configuration files) works around this. Using the .mvn directory is already possible with Maven 3.
2. Set the root attribute in your parent POM to true. The root attribute is a new attribute of model version 4.1.0 and therefore can only be used with Maven 4. Note: That is also the cause, why this topic is listed in the model version 4.1.0 section.

Use <subprojects> instead of <modules>

In Maven 4 subprojects are no longer called modules. While the <modules> element is still supported, it was marked as deprecated in model version 4.1.0 and will get removed in a future version. So you should replace it with the new <subprojects> element instead.

<!-- Requires model version 4.0.0 (Maven 3, deprecated in model version 4.1.0) -->
 <modules>
     <module>ModuleA</module>
     <module>ModuleB</module>
 </modules>

<!-- Requires model version 4.1.0 (Maven 4) -->
 <subprojects>
     <subproject>ModuleA</subproject>
     <subproject>ModuleB</subproject>
 </subprojects>

Automatic versioning in multi subprojects setups

Maven 4 contains a lot of improvements for projects which contain subprojects. Those include automatic version detection of the parent and project own dependencies.

Using Maven 3 with model version 4.0.0 you need to declare those. While the parent's version always must be hardcoded, you can use the ${project.version property to declare another subproject as a dependency. Using Maven 4 and model version 4.1.0 those definitions are optional.

The following example of a pom.xml shows the associated part for a subproject called “SubprojectB”. This subproject declares its parent and the dependency to “SubprojectA”, which is also a subproject in the same multi subproject setup.

In Maven 3 with model version 4.0.0 such a declaration looks like the following.

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
   
   <modelVersion>4.0.0</modelVersion>
   <artifactId>SubprojectB</artifactId>
   
   <parent>
      <groupId>demo.maven</groupId>
      <artifactId>TheParentProjecct</artifactId>
      <!-- The parents version must be "hardcoded" -->
      <version>0.0.1-SNAPSHOT</version>
   </parent>
   
   <dependencies>
      <dependency>
         <groupId>demo.maven</groupId>
         <artifactId>SubprojectA</artifactId>
         <!-- The subproject dependency version declaration can make use of the project.version property-->
         <version>${project.version}</version>
      </dependency>
   </dependencies>
   
   <!-- other declarations -->
</project>

In Maven 4 and model version 4.1.0 the version declaration are not needed anymore.

<project xmlns="http://maven.apache.org/POM/4.1.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.1.0 http://maven.apache.org/xsd/maven-4.1.0.xsd">
   
   <modelVersion>4.1.0</modelVersion>
   <artifactId>SubprojectB</artifactId>
   
   <parent>
      <groupId>demo.maven</groupId>
      <artifactId>TheParentProjecct</artifactId>
   </parent>
   
   <dependencies>
      <dependency>
         <groupId>demo.maven</groupId>
         <artifactId>SubprojectA</artifactId>
      </dependency>
   </dependencies>
   
   <!-- other declarations -->
</project>

CI-friendly variables without flatten-maven-plugin

Maven partially supports CI-friendly variables (like ${revision}) since version 3.5.0. Thanks to the improved dependency resolution of project own dependencies in multi subprojects setups they are now fully supported if you rely on the automatic versioning as described in the section above. This also means that you don't need the flatten-maven-plugin to install and deploy anymore.

Using BOM packaging

Maven 4 introduces a dedicated bom packaging type to provide a Bill of Materials BOM. This now differentiates between parent POMs and dependency-managing BOMs. The new type is only available as a build POM in Model Version 4.1.0 and later, but Maven generates a full Maven 3 compatible consumer POM during the build.

The following code snippet shows an example for a BOM using the new <packaging> type.

<project xmlns="http://maven.apache.org/POM/4.1.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.1.0 http://maven.apache.org/xsd/maven-4.1.0.xsd">

    <modelVersion>4.1.0</modelVersion>
    <groupId>demo.maven</groupId>
    <artifactId>Maven4-example-bom</artifactId>
    <version>1.0.0</version>

    <packaging>bom</packaging>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>dev.some.group</groupId>
                <artifactId>someArtifact</artifactId>
                <version>1.2.3</version>
            </dependency>
            <dependency>
                <groupId>dev.some.other</groupId>
                <artifactId>somethingElse</artifactId>
                <version>3.1.5</version>
            </dependency>
        </dependencies>
    </dependencyManagement>
</project>