Apache Maven,a software project management tool

@QuadraticBEJul. 2014

So it’s done...

I’m Renato Primavera from Quadratic

I write software that helps customers to manage and make use of their geographical data

@RenatoPrimavera renato.primavera@quadratic.be

www.quadratic.be

Maven can manage a project's

build, reporting and

documentation from a central piece

of information: the “POM”

The concept of POM, for

Project Object Model is the base of Maven

<proje

ct>

<mod

elVers

ion>4.

0.0</m

odelVe

rsion>

<gro

upId>c

om.myc

ompany

.app</

groupI

d>

<art

ifactI

d>my-a

pp</ar

tifact

Id>

<ver

sion>1

</vers

ion>

</proj

ect>

Here is a “POM”...

Maven makes the build process easy

> mvn clean Deletes any build output (e.g. class files or JARs)

> mvn test Runs the unit tests for the project

> mvn package Build the project artifacts (e.g. JAR or WAR)

> mvn site Creates project documentation (e.g. reports or Javadoc)

Maven provides a uniform build system

A project is always built using its project object model (POM)

and a set of plugins that are shared by all projects using Maven

Maven also provides guidelines for

best practices development

Keeping your test source code in a separate, but parallel source tree

Using test case naming conventions to locate and execute tests

Layout your project’s directory structure (so that once you learn the layout, you can easily navigate any other project that uses Maven and the same defaults ! )

> Ok> In practice now

Maven Installation Prerequisite: Maven is a Java tool, so you must have

Java installed in order to use it. More precisely, you need a JDK, the JRE is not sufficient

First...Download Maven (tar.gz / zip)

http://maven.apache.org/download.cgi

Then…

Unzip the distribution archive to the directory you wish to install Maven

Add the M2_HOME environment variable, pointing to that directory

Append the value $M2_HOME/bin to the PATH environment variable

#1

#2

#3

Make sure that JAVA_HOME exists as environment variable and it is set to the location of your JDK

[Optional] add the MAVEN_OPTS environment variable to specify JVM properties, e.g. the value -Xms256m -Xmx512m. This can be used to supply extra options to Maven

Open a command prompt and run mvn --version to verify that it is correctly installed

#4

#5

#6

Maven is now installed. It’s quite simple, isn’t it?

Let’s create a project> mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

What has been generated? (the project structure)

The POM file

The sources tree

The tests sources tree

What the POM file looks like...

What did you just do?

You executed the Maven goal “archetype:generate”, and passed in various parameters to

that goal

The prefix “archetype” is the plugin that contains the goal

The “generate” goal of the “archetype” plugin created a simple project based upon

an archetype

Suffice it to say for now that a plugin is a collection of goals with a general common purpose (e.g. the “release” plugin provides goals that allow to release projects - updating the

POM and tagging in the SCM)

We can now Build that project (and so generate a JAR artifact…)

> mvn package

...[INFO] ------------------------------------------------------------------------[INFO] BUILD SUCCESSFUL[INFO] ------------------------------------------------------------------------[INFO] Total time: 2 seconds[INFO] Finished at: Thu Jul 07 21:34:52 CEST 2011[INFO] Final Memory: 3M/6M[INFO] ------------------------------------------------------------------------

The command line will print out various actions, and end with the following:

Unlike the first command executed (archetype:generate) you may notice the

second is simply a single word - “package”

Rather than a goal, this is a phase

A phase is a step in the build lifecycle (which is an ordered sequence of phases)

When a phase is given, Maven will execute every phase in the sequence up to and including the one defined

For example, if we execute the compile phase, the phases that actually get executed are:

- validate- generate-sources- process-sources- generate-resources- process-resources- compile

These are the most common default lifecycle phases executed

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. These tests should not require the code be packaged or

deployed

package: take the compiled code and package it in its distributable format, such as a JAR

integration-test: process and deploy the package if necessary into an environment

where integration tests can be run

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: done in an integration or release environment, copies the final package to the

remote repository for sharing with other developers and projects

There are two other really useful Maven lifecycles phases

clean: cleans up artifacts created by prior builds

site: generates site documentation for this project

You said… Repository ?

Sir, yes Sir

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

Local repository is on your machine

It’s yours...

Remote repositories refer to any other type of repository, accessed by a variety of protocols such as file:// and http://

Such repository might be a truly remote repository set up by a third party to provide their

artifacts for downloading

Other "remote" repositories may be internal repositories set up on a file or

HTTP server within your company

These are used to share private artifacts between development teams and for releases

mvn install: installs the package into the local repository (for use as a dependency in other projects locally)Reminder

mvn deploy: deploys the final package to the remote repository ,i.e. the corporate one (for sharing with other developers and projects)

Before deploying any artifactto a remote repository, you must

configure that repo !

Using the distributionManagement section in your POM

or using the repositories section in your settings.xml file

<distributionManagement>

<!-- use the following if you're not using a snapshot version. -->

<repository>

<id>repo</id>

<name>Repository Name</name>

<url>scp://host/path/to/repo</url>

</repository>

<!-- use the following if you ARE using a snapshot version. -->

<snapshotRepository>

<id>repo</id>

<name>Repository Name</name>

<url>scp://host/path/to/repo</url>

</snapshotRepository>

</distributionManagement>

in thePOM

More about...

POM

The POM contains all necessary information about a project, as well as

configurations of plugins to be used during the build process

It is, effectively, the declarative manifestation of the “who”, “what” and “where” of your project

(while the build lifecycle is the “when” and “how”)

The Super POM is Maven's default POM

All POMs extend the Super POM unless explicitly set, meaning the configuration specified in the Super POM is inherited by the POMs you created

for your projects

By default, the build directory is “target”By default, the source directory is “src/main/java”

By default, the test source directory is “src/main/test”

and so on...

Examples for this

Super POM brings also the basic plugins...

maven-compiler-plugin

maven-dependency-pluginmaven-deploy-plugin

maven-jar-pluginmaven-javadoc-plugin

...

One powerful aspect of Maven is in its handling of

project relationships

That includes dependencies (and transitive dependencies),

inheritance, and aggregation (multi-module projects)

<dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.0</version> <type>jar</type> <scope>test</scope> <optional>true</optional> </dependency> ... </dependencies>

in thePOM

The cornerstone of the POM is its dependency list

Maven downloads and links the dependencies for you on compilation and other goals that require them

As an added bonus, Maven brings in the dependencies of those dependencies

(transitive dependencies), allowing your list to focus solely on the dependencies your

project requires

One powerful addition that Maven brings to build management is the concept of

project inheritance

<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>org.codehaus.mojo</groupId> <artifactId>my-parent</artifactId> <version>2.0</version> <packaging>pom</packaging></project>

The packaging type required to be “pom” for parent and aggregation

(multi-module) projects

<project xmlns="http://maven.apache.org/POM/4.0.0" ...>

<modelVersion>4.0.0</modelVersion>

<parent> <groupId>org.codehaus.mojo</groupId> <artifactId>my-parent</artifactId> <version>2.0</version> <relativePath>../my-parent</relativePath> </parent>

<artifactId>my-project</artifactId></project>

Parent POM still has to be referenced by children

Default value, if omitted, is “../pom.xml”

Useless if parent has already been installed

Once defined, we may add values to this parent POM, which will be inherited by

its children

For instance, sections like dependencyManagement (or

pluginManagement) can be defined in the parent POM

Dependency management allows to directly specify the versions of artifacts to be used when they are

encountered in transitive dependencies or in dependencies of children POM and where no version has been specified

In another words, the dependency management section is a mechanism

for centralizing dependency information

When you have a set of projects that inherits a common parent it's possible to put all information about the dependency in the common POM and have simpler

references to the artifacts in the child POMs

<project>

...

<dependencyManagement>

<dependency>

<groupId>my.groupid</groupId>

<artifactId>my-artifact</artifactId>

<version>1.0</version>

<scope>runtime</scope>

</dependency>

</dependencyManagement>

</project>

In Parent POM

<project>

...

<dependencies>

<dependency>

<groupId>another.groupid</groupId>

<artifactId>another-artifact</artifactId>

<version>2.1.3</version>

</dependency>

<dependency>

<groupId>my.groupid</groupId>

<artifactId>my-artifact</artifactId>

</dependency>

</dependencies>

</project>

In Children POM

A project with modules is known as a multimodule, or aggregator

project

Modules are projects that this POM lists, and are executed as a group

<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>org.codehaus.mojo</groupId> <artifactId>my-parent</artifactId> <version>2.0</version> <packaging>pom</packaging>

<modules> <module>my-project</module> <module>another-project</module> </modules></project>

An pom packaged project may aggregate the build of a set of

projects by listing them as modules, which are relative directories to those projects

Sourceshttp://maven.apache.org/

http://en.wikipedia.org/wiki/Apache_Maven

Thanks