POM extending and overriding

Let's see how POM overriding works. In the following example, we extend the repositories section to add one more repository to what is defined in the Maven super POM file:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.packt</groupId>
  <artifactId>sample-one</artifactId>
  <version>1.0.0</version>

  <repositories>
    <repository>
      <id>wso2-nexus</id>
      <name>WSO2 internal Repository</name>
      <url>http://maven.wso2.org/nexus/content/groups/wso2-public/
      </url>
      <releases>
        <enabled>true</enabled>
        <updatePolicy>daily</updatePolicy>
        <checksumPolicy>ignore</checksumPolicy>
      </releases>
    </repository>
  </repositories>

</project>

Type the following command from the directory, where you have the previous POM file:

$ mvn help:effective-pom

This will display the effective POM file for the application, which combines all the default settings from the super POM file and the configuration defined in your application POM. In the following code snippet, you can see that the <repositories> section in the super POM file is being extended by your application specific configuration. Now the <repositories> section has the central repository defined in the super POM file as well as your application specific repository:

<repositories>
  <repository>
      <releases>
        <enabled>true</enabled>
        <updatePolicy>daily</updatePolicy>
        <checksumPolicy>ignore</checksumPolicy>
      </releases>
      <id>wso2-nexus</id>
      <name>WSO2 internal Repository</name>
      <url>
        http://maven.wso2.org/nexus/content/groups/wso2-public/
      </url>
    </repository>
    <repository>
      <snapshots>
        <enabled>false</enabled>
      </snapshots>
      <id>central</id>
      <name>Central Repository</name>
      <url>https://repo.maven.apache.org/maven2</url>
  </repository>
</repositories>

If you want to override any of the configuration elements corresponding to the Maven central repository, inherited from the super POM file, then you have to define a repository in your application POM with the same repository id (as of the Maven central repository) and override the configuration element you need.

One main advantage of the POM hierarchy in Maven is that you can extend as well as override the configuration inherited from the top. Say for example, you might need to keep all the plugins defined in the super POM file, but just want to override the version of maven-release-plugin. The following configuration shows how to do it. By default, in the super POM, the maven-release-plugin version is 2.3.2, and here we update it to 2.5 in our application POM. If you run mvn help:effective-pom again against the updated POM file, you will notice that the plugin version is updated while the rest of the plugin configuration from the super POM file remain unchanged:

<project>

  <modelVersion>4.0.0</modelVersion>
  <groupId>com.packt</groupId>
  <artifactId>sample-one</artifactId>
  <version>1.0.0</version>

  <build>
    <pluginManagement>
      <plugins>
        <plugin>
          <artifactId>maven-release-plugin</artifactId>
          <version>2.5</version>
        </plugin>
      </plugins>
    </pluginManagement>
  </build>

</project>

To override the configuration of a given element or an artifact in the POM hierarchy, Maven should be able to uniquely identify the corresponding artifact. In the preceding scenario, the plugin was identified by its artifactId. In Chapter 5, Maven Plugins, we will further discuss how Maven locates plugins.