Introduction to Maven
Maven is a very flexible build tool. To understand it, you need to understand the following concepts:
- projects and the POM
- plugins and their goals
- build life cycle and phases
- packaging types
- dependency management and the local repository
Projects and the POM
In Maven, the unit of work is a project. Each project has its project object model (usually shortened to POM) defined in
pom.xml, an XML file that contains information about the project and details instructing Maven how to build the project. A project's POM can inherit from another project's POM to form a POM inheritance hierarchy; this is the mechanism used in Maven to avoid duplication. Eventually, all POM files inherit from the Maven Super POM.
Plugins and goals
As its plugin documentation states, Maven is "at its heart - a plugin execution framework; all work is done by plugins". There are countless plugins, such as:
- Compiler plugin - compiles Java code
- Surefire plugin - runs Java tests
- Checkstyle plugin - analyzes Java source code
- Cobertura plugin - runs unit tests and measure their coverage
- Dependency plugin - analyzes Java dependencies
Each plugin defines one or more goals. For example, the Compiler Plugin has two goals -
compile to compile the production code and
test-compile to compile automated tests.
Build life cycle and phases
Maven defines a build lifecycle that consists of a sequence of phases. For example, here are some phases of Maven's default life cycle:
compile- compiles the project's source code (in other words, create
.classfiles from the
test- runs the project's automated tests
package- takes the compiled code and packages it in its distributable format (for example, put all the
.classfiles into a JAR)
install- installs the project's artifact into the local repository, for use as a dependency in other projects locally
deploy- deploys the project's artifact to the artifact repository, usually Nexus (this phase should not normally be run by a developer)
Each phase of Maven's build life cycle is configured to run a specific goal of a specific plugin. Maven is configured with reasonable defaults for the plugin and goal to run in each phase. For example, the Compiler Plugin's compile goal is configured to run during Maven's compile phase. The Compiler Plugin's test-compile goal is configured to run during Maven's test-compile phase. (The overloaded use of terms such as compile can get confusing, but you get used to it.)
The most important aspect of a Maven project is its packaging type, which specifies the type of artifact the project produces. There are many built-in Maven packaging types (for example,
ear). A project's packaging type specifies the plugin goals that are executed during each Maven build phase. For example, in a
jar project, the
jar goal is executed. In a
war project, the
war goal is executed.
Dependency management and the local repository
Maven uniquely identifies all artifacts using a group ID, artifact ID, version, and type (these values are collectively referred to as an artifact's Maven coordinates).
With Maven, you never have to store artifacts that you depend on in source control... hallelujah! No more
lib folders in source control that have no traceability and have to be checked out as part of every submission!
Instead of artifacts in source control, a Maven build gets artifacts from the local Maven repository. For example, if my machine compiles two projects that use the same version of
log4j, only one copy of
log4j.jar exists on my machine. The artifact is only downloaded once. In a corporate environment, projects are typically configured to download all of their artifacts from a corporate repository (such as Nexus).
On a Windows XP machine, the Maven local repository is stored in the
C:\Documents and Settings\USERID\.m2\repository folder. Get to know where the local Maven repository is stored on your machine!