Introduction to Apache Maven: A build framework & build automation tool

For a quite while I had been using Ant build tool for building my Java projects. Since few days I have been switching to Apache Maven, an open source build framework that can be used to build almost all the projects in Java, .Net and other platforms. Maven was created by Sonatype’s Jason van Zyl in 2002.

What is Maven?

Maven, a Yiddish word meaning accumulator of knowledge, was originally started as an attempt to simplify the build processes in the Jakarta Turbine project. Maven is really a process of applying patterns to a build infrastructure in order to provide a coherent view of software projects.

Maven is a build tool

Maven 2.0 is based around the central concept of a build lifecycle. What this means is that the process for building and distributing a particular artifact (project) is clearly defined.
A Build Lifecycle is Made Up of Phases. Each of these build lifecycles is defined by a different list of build phases, wherein a build phase represents a stage in the lifecycle.

Maven is dependency management tool

Dependency management is one of the features of Maven that is best known to users and is one of the areas where Maven excels. There is not much difficulty in managing dependencies for a single a project, but when you start getting into dealing with multi-module projects and applications that consist of tens or hundreds of modules this is where Maven can help you a great deal in maintaining a high degree of control and stability.

A Documentation tool

Maven helps you to generate documentation of your project and create a Project Site. Not only does it generates the site code, but it can deploy the website on a server. 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 plugins, just like those used to build the project.
Internationalization in Maven is very simple, as long as the reports you are using have that particular locale defined.

Objectives of Maven

• Make the development process visible or transparent
• Provide an easy way to see the health and status of a project
• Decreasing training time for new developers
• Bringing together the tools required in a uniform way
• Preventing inconsistent setups
• Providing a standard development infrastructure across projects
• Focus energy on writing applications

Project Object Model (pom.xml)

A Project Object Model or POM 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 is the build directory, which is target; the source directory, which is src/main/java; the test source directory, which is src/main/test; 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, then executes the goal.

POM Sample

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.codehaus.cargo</groupId>
    <artifactId>cargo-core-api-container</artifactId>
    <name>Cargo Core Container API</name>
    <version>0.7-SNAPSHOT</version>
    <packaging>jar</packaging>
    <dependencies/> 
    <build/> 
[...]

* project – root
* modelVersion – should be set to 4.0.0
* groupId – the id of the project’s group.
* artifactId – the id of the artifact (project)
* version – the version of the artifact under the specified group

Build Profiles in Maven

Profiles are specified using a subset of the elements available in the POM itself (plus one extra section), and are triggered in any of a variety of ways. They modify the POM at build time, and are meant to be used in complementary sets to give equivalent-but-different parameters for a set of target environments (providing, for example, the path of the appserver root in the development, testing, and production environments). As such, profiles can easily lead to differing build results from different members of your team. However, used properly, profiles can be used while still preserving project portability. This will also minimize the use of -f option of maven which allows user to create another POM with different parameters or configuration to build which makes it more maintainable since it is runnning with one POM only.

Different types of Profile

* Per Project – Defined in the POM itself (pom.xml).
* Per User – Defined in the Maven-settings (%USER_HOME%/.m2/settings.xml).
* Global – Defined in the global maven-settings (%M2_HOME%/conf/settings.xml).
* Profile descriptor – a descriptor located in project basedir (profiles.xml)

Repositories in Maven

A repository in Maven is used to hold build artifacts and dependencies of varying types. There are strictly only two types of repositories: local and remote. The local repository refers to a copy on your own installation that is a cache of the remote downloads, and also contains the temporary build artifacts that you have not yet released. The local and remote repositories are structured the same way so that scripts can easily be run on either side, or they can be synced for offline used. In general use, the layout of the repositories is completely transparent to the Maven user, however.

Declaring a Remote Repository

Downloading in Maven is triggered by a project declaring a dependency that is not present in the local repository (or for a SNAPSHOT, when the remote repository contains one that is newer). By default, Maven will download from the central repository (http://repo1.maven.org/maven2/).
To override this, you need to specify a repositories element as follows:

<project>
  ...
  <repositories>
    <repository>
      <id>my-internal-site</id>
      <url>http://myserver/repo</url>
    </repository>
  </repositories>
  ...
</project>

Plugins in Maven

Maven is really just a core framework for a collection of Maven Plugins. In other words, plugins are where much of the real action is performed, plugins are used to: create jar files, create war files, compile code, unit test code, create project documentation, and on and on. Almost any action that you can think of performing on a project is implemented as a Maven plugin.
Plugins are the central feature of Maven that allow for the reuse of common build logic across multiple projects. They do this by executing an “action” (i.e. creating a WAR file or compiling unit tests) in the context of a project’s description – the Project Object Model (POM). Plugin behavior can be customized through a set of unique parameters which are exposed by a description of each plugin goal (or Mojo).