Maven - Tips and Tricks

Small Intro on Maven

There were several projects each with their own Ant build files that were all slightly different and JARs were checked into CVS. We wanted a standard way to build the projects, a clear definition of what the project consisted of, an easy way to publish project information and a way to share JARs across several projects.

The result is a maven tool that can now be used for building and managing any Java-based project.

Maven is a popular build tool available for java developers. It is is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information.

Maven Features:

  • Reduce the duplication of dependent software libraries (jars) required to build an application
  • Store all the software libraries in a remote store called a repository
  • Libraries private to the organization cannot be uploaded. By setting up an internal maven repository, an organization can avail of the benefits of a maven repository
  • Repository jars has been used by maven pom.xml files.

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. 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>

Now Parent POM is ready. :)

maven commands

mvn clean install

  • mvn: maven command, before using maven should be installed in ur machine and set maven environment variables.
  • clean: It will delete all previously compiled Java .class files and resources (like .properties) from project.
  • Install: will compile, test & package Java project and even install/copy your built .jar/.war file into local Maven repository.

mvn eclipse:eclipse

This will produce the following files for each module:
.classpath file
.project file

mvn -U clean install

Forces a check for updated releases and snapshots on remote repositories

mvn -o clean install

To work off-line with Maven, you need a local Maven repository which has all the needed artifacts.
-Dmaven.test.skip=true: test case skip
-Dfinbugs.test.skip=true: findbugs skip
-Denforcer.skip=true: enforcer skip

The Maven enforcer plugin

The Maven enforcer plugin lets you control or enforce constraints in your build environment. These could be the Maven version, Java version, operating system parameters, and even user-defined rules.

Here is the full command
mvn clean install && mvn eclipse:eclipse -Dmaven.test.skip -Dfindbugs.skip=true -Denforcer.skip=true