Intro Maven Build Lifecycles Goals

An introduction to

João Miguel Pereira
http://jpereira.eu
May 2012
An introduction to Maven by João Miguel Pereira is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0
Unported License.

An introduction to Maven
• Introduction
• Build Lifecycle
• Architecture
• Plug-ins and Goals
• Default phase bindings
• Repositories
• Artifacts
• Project Object Model
• Dependencies
• Archetypes

An introduction to Maven by João Miguel Pereira is licensed under a Creative Commons 2
Attribution-NonCommercial-ShareAlike 3.0 Unported License.

• Introduction
• Build Lifecycle
• Architecture
• Repositories
• Artifacts
• Dependencies
• Archetypes


The life before Maven
• Use javac in the command line to compile
your projects
• Rely on the IDE (Integrated Development
Environment) to have your project compiled
(Eclipse, NetBeans, IntelliJ IDEA, JDeveloper,...)
• Use ANT (Another Neat Tool)
• GNU Make


What is Maven
• Apache Project
• Born within Apache community to simplify the Jakarta
Turbine project
• Can generate deployable artifacts from source code
• Compile, pack, test and distribute your source code
• But it's not just “another build tool”
• It's more a Project Management tool than a “build
tool”
• It also create reports, generate a web site for the
project and facilitates communication among team
members


Why use Maven
• Manage all your project dependencies and life-
cycle
• Don't need to worry about having the
dependencies in your dev machine
• Convention over configuration means less
configuration
• Used in big and complex projects
• Let developers focus on what is really important
(coding)
• Based on XML to configure the project


• Introduction
• Build Lifecycle
• Architecture
• Repositories
• Artifacts
• Dependencies
• Archetypes


Maven Build Lifecycle
• Maven relies on build lifecycles to define the
process of building and distributing artifacts
(eg. Jar files, war files)
• There are three built-in build lifecycles
– Default – handles project building and
deployment
– Clean – handles project cleaning
– Site – handles project’s site generation


• Each Build Lifecycle is made up of phases
• Example:

Validate Compile Test Package Install

Deploy


• You can invoke a specific phase on the lifecyle
• Example: $ mvn test
• When you invoke a specific phase, every
previous phases run, including the one you
specified. If you run: $ mvn test

Validate Compile Test


Default lifecycle phases
Phase Description
validate Validate the project is correct and all necessary
information is available to complete a build
generate-sources Generate any source code for inclusion in compilation
process-sources Process the source code, for example to filter any values
generate-resources Generate resources for inclusion in the package
process-resources Copy and process the resources into the destination
directory, ready for packaging
compile Compile the source code of the project
process-classes Post-process the generated files from compilation, for
example to do bytecode enhancement on Java classes
generate-test- Generate any test source code for inclusion in
sources compilation


Default lifecycle phases (Continued…)
Phase Description
process-test- Process the test source code, for example to filter any
sources values
generate-test- Create resources for testing
resources
process-test- Copy and process the resources into the test destination
resources directory
test-compile Compile the test source code into the test destination
directory
test Run tests using a suitable unit testing framework. These
tests should not require the code be packaged or
deployed


Phase Description
prepare-package Perform any operations necessary to prepare a package
before the actual packaging. This often results in an
unpacked, processed version of the package (coming in
Maven 2.1+)
package Take the compiled code and package it in its distributable
format, such as a JAR, WAR, or EAR
pre-integration-test Perform actions required before integration tests are
executed. This may involve things such as setting up the
required environment
integration-test Process and deploy the package if necessary into an
environment where integration tests can be run
post-integration- Perform actions required after integration tests have
test been executed. This may include cleaning up the
environment


Phase Description
verify Run any checks to verify the package is valid and meets
quality criteria
install Install the package into the local repository, for use as a
dependency in other projects locally
deploy Copies the final package to the remote repository for
sharing with other developers and projects (usually only
relevant during a formal release)


Clean lifecycle phases
Phase Description
Pre-clean Run before the clean goal is
performed
Clean Clean the target folder
Post-clean Run after the clean goal is performed


Site lifecycle phases
Phase Description
Pre-site Run any goal that is needed before
the site generation
Site Generate the site
Post-site Run any goal that should be
performed after site generation
Site-deploy Deploy the site


• Introduction
• Build Lifecycle
• Architecture
• Repositories
• Artifacts
• Dependencies
• Archetypes


Maven architecture

Plug-in (1) Plug-in (2) Plug-in (3) Plug-in (n)

Core Engine

Remote
Remote Local
Repository
Remote
Repository Repository
Repositories

Maven architecture
• Core Engine provides:
– Project processing Read the project
configuration file and configure the project
accordingly.
– Build lifecycle management  Run a series of
phases (as seen before).
– Framework for plug-ins.


Maven architecture
• Plug-ins provides:
– The core operations to build your project. For
example, to create a jar the maven-jar-plugin will
do the job, not maven itself.
• Plug-ins provides one or more “Goals”
• A Goal perform some operation on the
project. Ex: compile, create a Jar, deploy to
Jboss, etc.
• Goals can be bound to build lifecycle phases

• Introduction
• Build Lifecycle
• Architecture
• Repositories
• Artifacts
• Dependencies
• Archetypes


Maven Plug-ins and Goals
• Goals can be bound to build-lifecycle phases.
Example:
Plug-in’s goals Bound by default to Lifecyle phase
Maven-compiler-plugin
Compile
Goal: compile

Goal: test-compile

Test-compile
Maven-surefire-plugin
Goal: test
Test


• Goals can be bound to build-lifecycle phases.
Example: $ mvn test

Validate Compile Test-Compile Test

Execute Execute Execute

Maven-compiler-plugin
Goal: compile Maven-surefire-plugin
Goal: test
Goal: test-compile


• We can bind a plug-in’s goal to a lifecycle
phase


Maven Lifecyle, Plug-ins and Goals
• Putting lifecycles, phases, plug-ins and goals
together….
– A lifecycle is a series of phases
– A phase is made of goals
– Goals are provided by plug-ins
• Each phase have default bindings


• Introduction
• Build Lifecycle
• Architecture
• Repositories
• Artifacts
• Dependencies
• Archetypes


Default phase bindings
• See http://maven.apache.org/guides/introduction/introduction-to-the-
lifecycle.html#Built-in_Lifecycle_Bindings


Default phase bindings(Continued…)


• Introduction
• Build Lifecycle
• Architecture
• Repositories
• Artifacts
• Dependencies
• Archetypes


Maven Repositories
• Used to hold build artifacts/dependencies
• Two types of repositories
– Remote
– Local


Maven Repositories
• Remote repositories
– Accessed by http://, file://, ftp:// or other
supported protocol
– Provided by a third party (example:
http://repo1.maven.org,
https://repository.jboss.org/nexus/)
– Provided by your company to distribute private
artifacts/dependencies


Maven Repositories
– By default, any Maven project use
http://repo1.maven.org/maven2, as a remote
repository
– Any number of remote repositories can be
configured


Maven Repositories
– Also hold plug-ins
– Plug-in repositories can be configured


Maven Repositories
• Local repositories
– Cache of dependencies and build artifacts used or
produced by your project, located in Maven’s
installation machine
– By default, located at
${user.home}/.m2/repository
– Can be overridden in file
${user.home}/.m2/settings.xml


• Introduction
• Build Lifecycle
• Architecture
• Repositories
• Artifacts
• Dependencies
• Archetypes


Maven artifacts
• An artifact is a file resulting from packaging a
project
• Can be a jar, war, ear, .xml file, for example
• Artifacts are deployed in repositories, so they
can be used, as dependencies, by other
projects


Maven artifacts
• Artifacts are identified by three components:
– Group Id  An unique identifier for a group of
related artifacts. Usually named like Java packages
(Ex: pt.jpereira.mobile)
– Artifact Id  An unique identifier, within the
context of GroupId, that identifies the artifact
(project). (Ex: puzzle)
– Version
• Also called artifact coordinates

• Introduction
• Build Lifecycle
• Architecture
• Repositories
• Artifacts
• Dependencies
• Archetypes


Project Object Model
• POM for short
• XML file located at the root of the project (pom.xml)
• The configuration for your project, including
– Information about the project
– Configuration details to build the project
– Contains default values for most of the projects. Ex:
Source dir, target dir
– Dependencies of the project
– Configuration about plugins and goals
– Used repositories
–…


• Minimum configuration is:
• 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


• Minimum configuration example


Super POM
• Every POM has a super POM
• What is not specified, and is required to build
the project, is inherited from a super POM

Super POM

Project’s POM


Project Inheritance
• Any POM, by default, inherit from the super
POM
• POM can inherit other POM, like class
inheritance in Java
Super POM

Project’s Parent POM

Project 1 POM Project 2 POM Project 3 POM


Project Inheritance
• Example of POM Inheritance

GroupId is also inherited

Minimum required


Project Inheritance
• A POM can override values from POMs higher
in the hierarchy
• An effective POM is the sum of all
configurations in the hierarchy of POMs
• You can see the effective POM by using:
– mvn help:effective-pom


Multi module POM
• A POM can aggregate multiple modules
• Commonly used configuration (remember the
n-tier architectures, for example)
• A POM can aggregate multiple modules and
be their parent POM at the same time


Multi module POM
• Example for Maven 2.2.2 project:

Module of

Parent POM and multi module POM


• Introduction
• Build Lifecycle
• Architecture
• Repositories
• Artifacts
• Dependencies
• Archetypes


Dependencies
• Selling point of Maven
• Managing hundreds of dependencies is hard
• Maven will manage the dependencies for you
• Dependencies are cached in you local
repository
• Transitive dependencies managed by Maven
• Multiple scopes for including dependencies


Declaring Dependencies
• Must provide the coordinates of the artifact:
– GroupId
– ArtifactId
– Version
• Declared in pom.xml
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.9</version>
<scope>test</scope>
</dependency>
</dependencies>


Dependency Management
• Mechanism to centralize dependency
information
• Have all information about dependencies in
the parent POM (version, exclusions, scope,
type)
• Child POMs only have to have a simple
reference to the dependencies, excluding
version, exclusions, scope type.


• Example:
Project A Project B
<project> <project>
<dependencies> <dependencies>
<dependency> <dependency>
<groupId>group-a</groupId> <groupId>group-c</groupId>
<artifactId>artifact-a</artifactId> <artifactId>artifact-b</artifactId>
<version>1.0</version> <version>1.0</version>
<exclusions> <type>war</type>
<exclusion> <scope>runtime</scope>
<groupId>group-c</groupId> </dependency>
<artifactId>ex-artif</artifactId> <dependency>
</exclusion> <groupId>group-a</groupId>
</exclusions> <artifactId>artifact-b</artifactId>
</dependency> <version>1.0</version>
<dependency> <type>jar</type>
<groupId>group-a</groupId> <scope>runtime</scope>
<artifactId>artifact-b</artifactId> </dependency>
<version>1.0</version> </dependencies>
<type>jar</type> </project>
<scope>runtime</scope>
</dependency>
</dependencies>
</project>


<project>
Parent POM <dependencyManagement>
<dependencies>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
<exclusions>
<exclusion>
<groupId>group-c</groupId>
<artifactId>excluded-artifact</artifactId>
</exclusion>
</exclusions>
</dependency>
Put here all information about <dependency>
<groupId>group-c</groupId>
dependencies <artifactId>artifact-b</artifactId>
<type>war</type>
</dependency>
<dependency>
<artifactId>artifact-b</artifactId>
<type>jar</type>
</dependency>
</dependencies>
</dependencyManagement>
</project>


Parent POM

Project A Project B


• Simplified POMs:
Project A Project B
<project> <project>
<parent> <parent>
<groupId>GroupParent</groupId> <groupId>GroupParent</groupId>
<artifactId>parentPOM</artifactId> <artifactId>parentPOM</artifactId>
</parent> </parent>
<dependencies> <dependencies>
<artifactId>artifact-a</artifactId> <artifactId>artifact-b</artifactId>
</dependency> <type>war</type>
<dependency> </dependency>
<groupId>group-a</groupId> <dependency>
<artifactId>artifact-b</artifactId> <groupId>group-a</groupId>
</dependency> <artifactId>artifact-b</artifactId>
</dependencies> </dependency>
</project> </dependencies>
</project>


Cache Dependencies

Depends
Your Project
Effective use

LIB_A_V1 LIB_B_V1 LIB_C_V2 LIB_A_V1 LIB_B_V1 LIB_C_V2
Download

Remote Local
Repositories Repository (Cache)


Transitive dependencies
• Maven will manage the dependencies of your
dependencies Your Project

LIB_A_V1 LIB_B_V1 LIB_C_V2

LIB_D_V1 LIB_E_V1 LIB_E_V1 LIB_F_V1 LIB_G_V1 LIB_H_V1 LIB_I_V1

LIB_j_V1 LIB_K_V1 LIB_L_V1 LIB_M_V1 LIB_N_V1 LIB_O_V1 LIB_P_V1 LIB_Q_V1


Dependency Mediation
• If version not explicit, Maven will use the
nearest definition in the tree
Your Project

A 1.0 B 1.0 C 1.0

D 1.0 E 1.0
Which version of F will be used?

F 1.0 G 1.0

F 2.0

Dependency Mediation
• If version not explicit, Maven will use the
nearest definition in the tree
Your Project

A 1.0 B 1.0 C 1.0

D 1.0 E 1.0
Which version of F will be used?
F 1.0 is the neareast in the tree
F 1.0 G 1.0

F 2.0

Dependency Scope
• Allows you to only include dependencies
appropriate for the current stage of the build
• You don’t need all dependencies in all situations
• Examples:
– Why would you need to distribute JUnit library if you
are not distributing tests to your customers?
– Why would you package hibernate.jar into your ear
file, if you will deploy your application to Jboss that
already provides hibernate.jar?


Available Scopes
• 6 Available Scopes
– Compile
– Provided
– Runtime
– Test
– System
– Import (Maven 2.0.9 onwards)


Compile Dependency
• Default for dependencies not specifying scope
• Available to all classpaths of build lifecycle
(compile, test-compile, test, package)
• Packaged into final artifact
• Required by user projects, i.e., by projects that
depends on the one declaring the dependency.
– Example: If your project (Y) depends on project X, with
scope compile, then any project (U) that depends on
your project (Y) will transitively depends on X.


Compile Dependency

U
Compile Dependency Will use X in all
classpaths and packaged
artifact

Your Project (Y)

Compile Dependency

X

Provided Dependency
• Available to compile ant test classpaths
• Not packaged as part of your artifact
• It’s expected the container, where the artifact
will be used, to provide the dependency
– Example: Use of servlet-api for compilation and
testing but will not distribute the servlet-api with
the artifact, because is expected that the Servlet
container to provide that dependency


Runtime Dependency
• This dependency is not required for compiling
your project
• Is required at runtime, when your application
run
• Also required when testing because tests will
execute main code


Runtime Dependency
X’s API does not need
Z, however X’s API
implementation
Your Project (Y) requires Z, thus Z is
required to run Y but
not compiling it.
Compile Dependency

API

X Implementation

Runtime Dependency

Z

Test Dependency
• This dependency is only required to compile
and run test
• Will not be packaged into final assembly (Jar,
War, Ear, etc)
• Not needed when compiling or running main
code


System Dependency
• Similar to Provided Dependency
• Not looked up in repository
• Expected to exists in your development machine
• Have to give full path to the dependency using
<systemPath>
• Used only for rare cases where the build depend
on the machine where the build process is taking
place
• Not recommended


Import Dependency
• Only available on Maven 2.0.9 onwards
• Used to import dependencies from other POM
• Used with Dependency Management
<dependencyManagement>
• Use if you want to centralize all dependency
management into a single project (in this case
is that project will produces an POM file)


Import Dependency
Dependencies POM
groupX:artifactX:1.0 (GroupId:ArtifactId:Version)
<project>
<dependencyManagement>
<dependencies>
<dependency> <project>
<groupId>group-a</groupId> <dependencyManagement>
<artifactId>artifact-a</artifactId> <dependencies>
<version>1.0</version> <dependency>
</dependency> <groupId>groupX</groupId>
<dependency> <artifactId>artifactX</artifactId>
<groupId>group-c</groupId> <version>1.0</version>
<artifactId>artifact-b</artifactId> <type>pom</type>
<version>1.0</version> <scope>import</scope>
<type>war</type> </dependency>
<scope>runtime</scope> </dependencyManagement>
</dependency> <dependencies>
<artifactId>artifact-b</artifactId> <artifactId>artifact-b</artifactId>
<type>war</type>
</dependency>
<type>jar</type>
<dependency>
</dependency> <artifactId>artifact-b</artifactId>
</dependencies> </dependency>
</dependencyManagement> </dependencies>
</project> </project>


Excluded Dependencies
• Transitive dependencies can be excluded from
dependency tree
Your Project (Y)

X X
Transitive dependency

Z

Excluded Dependencies
<dependencies>
<dependency>
<groupId>GroupX</groupId>
<artifactId>ArtifactX</artifactId>
<exclusions>
<exclusion>
<groupId>GroupZ</groupId>
<artifactId>ArtifactZ</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>


Optional Dependencies
• Optional dependencies are excluded by
default
Your Project (Y)

X X
Transitive dependency

Optional

Z

• Introduction
• Build Lifecycle
• Architecture
• Repositories
• Artifacts
• Dependencies
• Archetypes

Maven archetypes
• An archetype is a project template
• Contains the common configurations for
projects of the same type
• Example: All JPA2.0 projects contains the
dependencies to JPA2.0 API
• You can create your archetypes from a project
• Archetypes are deployed in repositories


Maven archetypes
• Using archetypes:
– mvn archetype:generate
• Create archetype from current project
– mvn archetype:create-from-project


Everything about…
• Maven:
– http://maven.apache.org/
– http://www.sonatype.com/books/mvnref-
book/reference/
• POM:
– http://maven.apache.org/pom.html


Intro Maven Build Lifecycles Goals

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Intro Maven Build Lifecycles Goals

Similar to Intro Maven Build Lifecycles Goals (20)

Recently uploaded

Recently uploaded (20)

Intro Maven Build Lifecycles Goals