Maven

Introduction

Apache Maven 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 uses Convention over Configuration. Developers do not have to mention each and every configuration detail. Maven provides sensible default behavior for projects, like “jar” for the packaging type.

Running Maven

The syntax for running Maven is as follows:
$ mvn [options] [<goal(s)>] [<phase(s)>]

All available options are documented here and in the built-in help:
$ mvn -h
Some of the options are:
-D,--define : Define a system property
-P,--activate-profiles : Comma-delimited list of profiles to activate
-U,--update-snapshots : Forces a check for missing releases and updated snapshots on remote repositories

Typical invocation uses a Maven life cycle phase:
$ mvn verify

To invoke a specific task, a goal of a plugin, use for example:
$ mvn archetype:generate

Introduction to the POM

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.
When executing a phase or goal, Maven looks for the POM in the current directory. It reads the POM, gets the needed configuration information, then executes the goal.
The minimum requirement for a POM are the following:

  • 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

Example:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.mycompany.app</groupId>
  <artifactId>my-app</artifactId>
  <version>1.0.0-SNAPSHOT</version>
</project>

The groupId, artifactId, and version form the project’s fully qualified artifact name. It marks a specific place in a repository, acting like a coordinate system for Maven projects. More on other elements can be found here.

Build Lifecycles

Maven is based around the central concept of a build lifecycle. This means that the process for building and distributing a particular artifact (project) is clearly defined.
There are three built-in build lifecycles

  • the default lifecycle handles your project deployment
  • the clean lifecycle handles project cleaning
  • the site lifecycle handles the creation of your project’s site documentation

Build Phases

Each build lifecycles is defined by a different list of build phases, wherein a build phase represents a stage in the lifecycle. All phases of the clean lifecycle:

  • pre-clean : Execute processes needed prior to the actual project cleaning.
  • clean : Remove all files generated by the previous build.
  • post-clean : Execute processes needed to finalize the project cleaning.

Some phases of the default lifecycle:

  • validate : Validate the project is correct and all necessary information is available.
  • compile : Compile the source code of the project.
  • test : Test the compiled source code using a suitable unit testing framework.
  • package : Take the compiled code and package it in its distributable format, such as a JAR.
  • verify : Run any checks on results of integration tests to ensure quality criteria are met.
  • install : Install the package into the local repository.
  • deploy : Copy the final package to the remote repository.

When a phase is given, Maven will execute every phase in the sequence of the corresponding lifecycle up to and including the one defined.
A complete list of all phases of the built-in lifecycles can be found here.

Plugin Goals

The manner in which a build phase carries out a specific step in the build lifecycle may vary. This is done by declaring the plugin goals bound to those build phases. A plugin goal represents a specific task (finer than a build phase) which contributes to the building and managing of a project.

A plugin goal may be bound to zero or more build phases. A goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation. The order of execution depends on the order in which the goal(s) and the build phase(s) are invoked.
For example:
$ mvn clean dependency:copy-dependencies package

  • The clean phase will be executed first (meaning it will run all preceding phases of the clean lifecycle, plus the clean phase itself).
  • Then the dependency:copy-dependencies goal (of a plugin).
  • Finally the package phase (and all its preceding build phases of the default lifecycle) will be executed.

Plugins

Plugins are artifacts that provide goals to Maven. A plugin may have one or more goals wherein each goal represents a capability of that plugin. Plugins can contain information that indicates which lifecycle phase to bind a goal to. More on plugins can be found here.

Binding Plugin Goals to Build Phases

The clean and site lifecycle are defined directly with their plugin bindings. The default lifecycle is defined without any associated plugin.
The most common way to bind goals to build phases of the default lifecycle is to set the POM element <packaging>. Each packaging contains a list of goals to bind to a particular phase. A complete list of the bindings for each packaging can be found here.

Examples

References