Maven - Parent POM

POM ( Project Object Model):

A POM (Project Object Model) is the fundamental unit of work in Maven.It is an XML file that contains information about the project and configuration details used by Maven to build the project.It contains default values for most projects. Examples for this are the build directory, which is "target"; the source directory, which is "src/main/java"; the test source directory, which is "src/main/test"; List of jars entries and so on.

The POM was renamed from project.xml in Maven 1 to "pom.xml"in Maven 2. Instead of having a "maven.xml"file that contains the goals that can be executed, the goals or plugins are now configured in the "pom.xml". When executing a task or goal, Maven looks for the POM in the current directory. It reads the POM, gets the needed configuration information, and then executes the goal.

Parent POM


Parent pom also one pom. There is no big difference between parent pom and normal pom.

Then why parent pom????

Whenever we go with application having multiple services or projects, each project we have to specify "pom. xml" with all the jars which are useful for that. Especially some jars will be common for all the application like spring jars, testing related jars, logging related jars and if our project is mule related means mule related entries.

So Instead of having same jars entries in all the poms, will specify the common entries in parent pom. After that each application/Project will inherit the parent pom and will utilize the entries from that parent pom.

What is the Use to having Parent pom?
  • Individual entries will be reduced by inheriting parent pom (re-usability).
  • Will have a control and uniformity on poms.
    Ex: Any change comes in dependency version that will be reflected in all the inherited poms. By this approach, we can avoid issues with version differences between applications.
  • Have a chance to implement multi-modules concept.

How to create parent pom?


1). Packaging need to follow as "pom".

<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>
	<groupId>com.javavillage</groupId>
	<artifactId>MyParent</artifactId>
	<version>4.0.0-SNAPSHOT</version>
	<packaging>pom</packaging>
	<name>Parent with Multi modules</name>

</project>

2). Creating properties for versions(optional): This is the best standard which we have to follow. If we use this, Any version change comes no need to go each module and change the version. For example now I am using spring related jars with 2.X.X and then days goes on I may plan to migrate to 3.X.X. Just change the property value and that will effected to all the modules. And one more advantage you can able to override this property by sub modules also.

<properties>
	<muleVersion>3.2.1</muleVersion>
	<muleJdbcVersion>3.2.1.1</muleJdbcVersion>
	<spring.version>3.0.3.RELEASE</spring.version>
	<mysql.connector.version>5.1.16</mysql.connector.version>
	<jdk.version>1.6</jdk.version>
	<slf.version>1.7.2</slf.version>
</properties>

3). Include all dependencies in dependencyManagement. Below entries just an example. You need to add jar entries as per your project.

<dependencyManagement>
	<dependencies>
		<dependency>
			<groupId>com.mulesoft.muleesb</groupId>
			<artifactId>mule-core-ee</artifactId>
			<version>${muleVersion}</version>
			<scope>provided</scope>
		</dependency>
		<dependency>
			<groupId>com.sun.xml.bind</groupId>
			<artifactId>jaxb-impl</artifactId>
			<version>2.1.13</version>
			<type>jar</type>
		</dependency>
		<dependency>
			<groupId>commons-jxpath</groupId>
			<artifactId>commons-jxpath</artifactId>
			<version>1.3</version>
			<scope>test</scope>
		</dependency>
		<dependency>
			<groupId>org.slf4j</groupId>
			<artifactId>slf4j-log4j12</artifactId>
			<version>${slf.version}</version>
			<type>jar</type>
			<scope>compile</scope>
		</dependency>
		<dependency>
			<groupId>mysql</groupId>
			<artifactId>mysql-connector-java</artifactId>
			<version>${mysql.connector.version}</version>
			<type>jar</type>
			<scope>provided</scope>
		</dependency>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>4.10</version>
			<type>jar</type>
			<scope>test</scope>
		</dependency>
	</dependencies>
</dependencyManagement>

<dependencyManagement> tag is for only for parent pom. This tag we can't use for submodules.Maven provides a way for you to consolidate dependency version numbers in the dependencyManagement element. You'll usually see the dependencyManagement element in a top-level parent POM for an organization or project. Using the dependencyManagement element in a pom.xml allows you to reference a dependency in a child project without having to explicitly list the version. Maven will walk up the parent-child hierarchy until it finds a project with a dependencyManagement element, it will then use the version specified in this dependencyManagement element.

4). Plugins:
plugin inside plugins. Again pluginManagement same as dependencyManagement. because pluginManagement is a way to share the same plugin configuration across all your project modules.

<build><pluginManagement><plugins>
I. maven release
<plugin>
	<groupId>org.codehaus.mojo</groupId>
	<artifactId>cobertura-maven-plugin</artifactId>
	<version>2.5.2</version>
</plugin>
<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-release-plugin</artifactId>
	<configuration>
		<autoVersionSubmodules>true</autoVersionSubmodules>
		<preparationGoals>clean install</preparationGoals>
	</configuration>
</plugin>
II. PMD
<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-pmd-plugin</artifactId>
	<version>3.0.1</version>
	<configuration>
		<targetJdk>1.6</targetJdk>
	</configuration>
</plugin>
III. findbugs
<plugin>
	<groupId>org.codehaus.mojo</groupId>
	<artifactId>findbugs-maven-plugin</artifactId>
	<version>2.5.2</version>
	<configuration>
		<targetJdk>1.6</targetJdk>
	</configuration>
</plugin>

5). Configuring Reports
Maven has several reports that you can add to your web site to display the current state of the project. These reports take the form of plugin goals, just like those used to build the project. Maven Project Info Reports Plugin provides many standard reports by extracting information from the POM, for example:

  • Continous Integration
  • Dependencies
  • Issue Tracking
  • License
  • Mailing Lists
  • Project Team
  • Source Repository

To add these reports to your site, you must add the plugin to the <reporting> element in the POM. The following example shows how to configure the standard Project Info Reports that display information from the POM in a friendly format

<project>
	...
	<reporting>
		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-project-info-reports-plugin</artifactId>
				<version>2.6</version>
			</plugin>
		</plugins>
	</reporting>
	...
</project>

Selecting Reports from a Plugin: Configuring Report Sets By default, when you add a plugin in reporting section, every reporting goal available in the plugin is rendered once. If you want to choose only some reports from a plugin, or if you want to run a report multiple times with a different configuration, you need to configure report sets:

<project>
	...
	<reporting>
		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-project-info-reports-plugin</artifactId>
				<version>2.6</version>
				<reportSets>
					<reportSet>
						<reports><!-- select reports -->
							<report>index</report>
						</reports>
						<reportSet>
				</reportSets>
			</plugin>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-javadoc-plugin</artifactId>
				<version>2.9</version>
				<reportSets>
					<reportSet><!-- by default, id = "default" -->
						<reports><!-- select non-aggregate reports -->
							<report>javadoc</report>
							<report>test-javadoc</report>
						</reports>
					</reportSet>
					<reportSet>
						<!--
						aggregate reportSet, to define in poms having modules
						-->
						<id>aggregate</id>
						<inherited>false</inherited>
						<!--
					    don't run aggregate in child modules
						-->
						<reports>
							<report>aggregate</report>
						</reports>
					</reportSet>
				</reportSets>
			</plugin>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-pmd-plugin</artifactId>
				<version>3.0.1</version>
				<reportSets>
					<reportSet>
						<reports><!-- select reports -->
							<report>pmd</report>
						</reports>
						<reportSet>
				</reportSets>
			</plugin>
		</plugins>
	</reporting>
	...
</project>

Notice: don't forget to define reportSets for plugins which provide aggregator reports, like maven-javadoc-plugin, maven-jxr-plugin or maven-checkstyle-plugin or you'll have these aggregate reports run by default in addition to non-aggregate reports. If you want activate or deactivate reports. you can create reports inside profiles. Based on profile name, in settings.xml we can activate or deactivate

<activeProfiles>
	<activeProfile>profile-1</activeProfile>
</activeProfiles>

Now Parent POM is ready. :)