by Amelia Ilies,

Kati Holasz

Summary

Introduction to MavenBasic Maven Project StructureBasic Maven POM FileRepositoriesMaven Build ProfilesMaven Plug-ins

FailSafe Plug-inSureFire Plug-in

ConclusionReferencesQ&A

IntroductionMaven. . . What is it? project management tool which encompasses a project object model, a set of standards, a project life-cycle, a dependency management system, and logic for executing plug-in goals at defined phases in a life-cycle.

Maven is :A top-level open source Apache Software Foundation projectA popular build toolA dependency management toolA release management tool

Project object model

Dependency management

model

Project life-cycle and phases

Plug-in Plug-in...

Repositories (local and rem

ote)

pom.xml

Maven Objectives

Making the build process easy

Providing a uniform build system

Providing quality project information

Allowing transparent migration to new features

4

Maven Features

simple project setup

able to easily work with multiple projects at the same time

extensible, with the ability to easily write plug-ins

instant access to new features

coherent site of project information

release management and distribution publication

dependency management

a large and growing repository of libraries and meta-data to use out of the box

What do we know?!

When you use Maven, you describe your project using a well-defined project object model, Maven can then apply cross-cutting logic from a set of shared (or custom) plugins.

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 is essentially a project management tool and as such provides a way to help with managing:

BuildsDocumentationReportingDependenciesReleasesDistribution

Key Concepts

Project Structure

POM File

Maven Repositories

Dependencies

Life-cycle phases

Maven Profiles

Plug-ins

Project Structure

Directory name Purposeproject home Contains the pom.xml and all sub-directories

src/main/java Contains the deliverable Java source-code for the project.src/main/resources Contains the deliverable resources for the project, such as property files.

src/test/java Contains the testing classes (Junit, for example) for the project.src/test/resources Contains resources necessary for testing.

Project Object Model (POM) → contains a complete description of how to build the current project.

folder created for the web-drivers

contains the result of the build, as well as all all of the intermediate files generated during the build.

package created for java files used only during the testing phase

project's source code

project's testing classes

configuration files, data files, or Java properties, only during the testing phase

POM

where a project’s identity and structure are declared, builds are configured, and projects are related to one another.

The presence of a pom.xml file defines a Maven project.

Without the POM, Maven is useless - the POM is Maven's currency. It is the POM that drives execution in Maven and this approach can be described as model-driven or declarative execution.

POM … What?!

Stands for Project Object ModelIs an XML documentIs Maven’s description of a single projectContains a detailed description of your project, including information about versioning and configuration management, dependencies, application and testing resources, team members and structure, and much more…

Minimal POM

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</groupId>

<artifactId>my-app</artifactId>

<version>1</version>

</project>

Pom.xml Structure

Dependences

<name>SE :: petals-se-perfo</name><artifactId>petals-se-perfo</artifactId><groupId>org.objectweb.petals</groupId><version>2.0</version><packaging>jbi-component</packaging><description>petals-se-perfodescription.</description><dependencies> <dependency><groupId>junit</groupId> <artifactId>junit</artifactId><version>3.8.2</version> <scope>test</scope></dependency><dependency>... </dependency></dependencies>

<build><plugins><plugin><groupId>org.objectweb.petals</groupId><artifactId>maven-petals-plugin</artifactId><version>1.1.1</version><extensions>true</extensions><configuration><source>1.5</source><target>1.5</target></configuration></plugin></plugins></build>

<repositories><repository><id>apache-snapshots</id><name>Apache SNAPSHOT Repository</name><urlhttp://people.apache.org/repo/m2-snapshot-repository/</url><snapshots><enabled>true</enabled></snapshots></repository>...<repositories>

Identification

Compilation

Other

The Super POM

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

Similar to the inheritance of objects in object oriented programming, POMs that extend a parent POM inherit certain values from that parent. Moreover, just as Java objects ultimately inherit from java.lang.Object, all Project Object Models inherit from a base Super POM.

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.

If you have several Maven projects, and they all have similar configurations, you can refactor your projects by pulling out those similar configurations and making a parent project. Thus, all you have to do is to let your Maven projects inherit that parent project, and those configurations would then be applied to all of them. And if you have a group of projects that are built or processed together, you can create a parent project and have that parent project declare those projects as its modules.

POM POM file <tags>project - the top-level element in all Maven pom.xml files.

modelVersion - required element - the version of the object model that the POM is using. The version of the model itself changes very infrequently, but it is mandatory in order to ensure stability when Maven introduces new features or other model changes.

groupId - unique identifier of the organization or group that created the project. The groupId is one of the key identifiers of a project and is typically based on the fully qualified domain name of your organization.

artifactId - unique base name of the primary artifact being generated by this project.

A typical artifact produced by Maven would have the form <artifactId>-<version>.<extension> (e.g: myapp-1.0.jar).

packaging – the package type to be used by this artifact (JAR, WAR, EAR, etc.). This not only means that the artifact produced is a JAR, WAR, or EAR, but also indicates a specific life cycle to use as part of the build process.

version - indicates the version of the artifact generated by the project. Maven goes a long way to help you with version management and you will often see the SNAPSHOT designator in a version, which indicates that a project is in a state of development.

name - indicates the display name used for the project. This is often used in Maven's generated documentation, and during the build process for your project, or other projects that use it as a dependency.

url - where the project's site can be found.

description - description of your project.

Maven Repositories→ are used to hold build artifacts and dependencies of varying

types.

Repository types:local repository

→ is a folder location on your machine. It gets created when you run any maven command for the first time. Maven local repository keeps your project's all dependencies (library jars, plug-in jars etc).

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

Dependencies are downloaded from repositories

→ via http (e.g: http://mvnrepository.com/)

Downloaded dependencies are cached in a local repository

→ usually found in ${user.home}/.m2/repository

Defining a repository

<project> ... <repositories> <repository> <id>lds-main</id> <name>LDS Main Repo</name> <url>http://code.lds.org/nexus/content/groups/main-repo</url> <snapshots> <enabled>false</enabled> </snapshots> </repository> </repositories></project>

Repositories are defined in the POM file (pom.xml)

Repositories can be inherited from parent

Repositories are keyed by id

Downloading snapshots can be controlled

Artifacts and Dependencies

Dependency Management

The key concept is that Maven dependencies are declarative. In the POM you are not specifically telling Maven where the dependencies are physically, you are simply telling Maven what a specific project expects.

Where does that dependency come from ?

When a dependency is declared, Maven tries to satisfy that dependency by looking in all of the remote repositories that are available, within the context of your project, for artifacts that match the dependency request. If a matching artifact is located, Maven transports it from that remote repository to your local repository for general use.

artifact → is a file (jar, war, ear, etc), that gets deployed to a Maven repository.

Maven provides a large database of artifacts in maven central repository http://search.maven.org/.

Profiles

are Maven's way of letting you create environmental variations in the build life cycle to accommodate things like building on different platforms, building with different JVMs, testing with different databases, or referencing the local file system.

You can define profiles in one of the following three places:The Maven settings file (typically <your -home-directory>/.m2/settings.xml)A file in the the same directory as the POM, called profiles.xmlThe POM itself

Maven Build Profiles

→ is a set of configuration values which can be used to set or override default values of Maven build. Using a build profile, you can customize build for different environments. Profiles are specified in pom.xml file using its activeProfiles / profiles elements and are triggered in variety of ways.

→ profiles can be activated in the Maven settings, via the <activeProfiles> section. Profiles listed in the <activeProfiles> tag would be activated by default every time a project use it.

→ profiles can be automatically triggered based on the detected state of the build environment. These triggers are specified via an <activation> section in the profile itself.

Types of Build Profile

Type Where it is defined

project Defined in the project POM file, pom.xml

user Defined in Maven settings xml file (%USER_HOME%/.m2/settings.xml)

global Defined in Maven global settings xml file (%M2_HOME%/conf/settings.xml)

How to Build Profiles

→ This option takes an argument that is a comma-delimited list of profile-ids to use. When this option is specified, no profiles other than those specified in the option argument will be activated.

mvn groupId:artifactId:goal -P profile-1,profile-2

→ Deactivating a profilemvn groupId:artifactId:goal -P !profile-1,!profile-2

Example:

<profiles> <profile> <id>profile-A</id> <dependencies> <dependency> <groupId>com.example</groupId> <artifactId>dependency</artifactId> <version>1.0.0</version> </dependency> </dependencies> </profile>

<profile> <id>profile-B</id> <dependencies> <dependency> <groupId>com.example</groupId> <artifactId>dependency</artifactId> <version>2.0.0</version> </dependency> </dependencies> </profile> </profiles>

Now you can invoke profile-A using the commandmvn -Pprofile-A install

Daily usage

– mvn compile (compile)– mvn install (compile, test, package, install)

mvn –N installTake a look at your local repository.mvn –Nmvn install -Dmaven.test.skip=true

mvn cleanInspect content of current directory.

mvn compileInspect directory target.

mvn testmvn surefire:testmvn failsafe:testProfiles can be selected on the command line:mvn –P orion2x,resin3x installWhat is the difference between “mvn surefire:test” and “mvn test”?

Life-cycle phasesThese are the most common default life-cycle 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 Maven lifecycles of note beyond the default list above.

clean: cleans up artifacts created by prior builds

site: generates site documentation for this project

Phases are actually mapped to underlying goals. The specific goals executed per phase is dependant upon the packaging type

of the project.

Life-cycle Phase Mojo Pluginprocess-resources resources maven-resources-plugin

compile compile maven-compiler-plugin

process-test-resources testResources maven-resources-plugin

test-Compile testCompile maven-compiler-plugin

test test maven-surfire-plugin

package jar maven-jar-plugin

install install maven-install-plugin

deploy deploy maven-deploy-plugin

As a specific example of how plug ins work together through the lifecycle, consider a very basic Maven build: a project with source code that should be compiled and archived into a jar file for redistribution. During this build process, Maven will execute a default life cycle for the 'jar' packaging. The 'jar' packaging definition assigns the following life-cycle phase bindings:

Life-cycle phases and specific plug-ins

Life-cycle phase Mojo Plug-in

Universal Reuse through Maven Plug-ins

Maven is actually a platform that executes plug-ins within a build life cycle, in order to perform the tasks necessary to build a project.

Maven has been designed to delegate most responsibility to a set of Maven Plug-ins which can affect the Maven Life-cycle and offer access to goals.

The fact that Maven retrieves both dependencies and plug-ins from the remote repository allows for universal reuse of build logic.

Plug-ins

Plugin Description

clean Clean up after the build.

compiler Compiles Java sources.

deploy Deploy the built artifact to the remote repository.

failsafe Run the JUnit integration tests in an isolated classloader.

install Install the built artifact into the local repository.

resources Copy the resources to the output directory for including in the JAR.

site Generate a site for the current project.

surefire Run the JUnit unit tests in an isolated classloader.

verifier Useful for integration tests - verifies the existence of certain conditions.

Maven is a plug-in execution framework; all work is done by plug-ins.Plug-ins are downloaded and installed automatically, if not present on your local system, in much the same way that a dependency is handled.

${home.repository}\.m2\repository\org\apache\maven\plugins

There are the build and the reporting plug-ins:Build plug-ins will be executed during the build and they should be configured in the <build/> element from the POM.

24

Plug-ins

Plugin Description

project-info-reports Generate standard project reports.

surefire-report Generate a report based on the results of unit tests.

changelog Generate a list of recent changes from your SCM.

changes Generate a report from an issue tracker or a change document.

javadoc Generate Javadoc for the project.

checkstyle Generate a Checkstyle report.

Reporting plug-ins will be executed during the site generation and they should be configured in the <reporting/> element from the POM. Because the result of a reporting plug-in is part of the generated site.

SureFire Plug-in

The Maven Surefire plugin is the plugin that is responsible for running unit tests.

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.12.2</version> <configuration> …. </configuration></plugin>

Note that the Surefire plugin (which executes the test) looks for tests contained in files with a particular naming convention. By default, the following tests are included:

**/*Test.java**/Test*.java**/*TestCase.java

To execute one Test at a time, run mvn test mvn -Dtest=MyUnitlTest

Execute tests:mvn testmvn surefire:test

FailSafe Plug-in

The Maven SafeFail plugin is the plugin that is responsible for running integration tests.

The Failsafe plugin will look, by default for: **/IT*.java**/*IT.java **/*ITCase.java

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-failsafe-plugin</artifactId> <version>2.12.2</version> <executions> <execution> <goals> <goal>integration-test</goal> <goal>verify</goal> </goals> </execution> </executions></plugin>

Execute tests:mvn testmvn failsafe:integration-testmvn failsafe:verify

FailSafe Plugin

The Maven lifecycle has four phases for running integration tests:

pre-integration-test for setting up the integration test environment.

integration-test for running the integration tests.

post-integration-test for tearing down the integration test environment.

verify for checking the results of the integration tests.

The advantage to using the Maven Failsafe Plugin is that it will not stop the build during the integration-test phase if there are test failures.

Inclusions and Exclusions of tests

Inclusions<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-failsafe-plugin</artifactId> <version>2.16</version> <configuration> <includes> <include>**/Sample.java</include> </includes> </configuration> </plugin>

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-failsafe-plugin</artifactId> <version>2.16</version> <configuration> <excludes> <exclude>**/OneIT.java</exclude> <exclude>**/TwoIT.java</exclude> </excludes> </configuration> </plugin>

FailSafe Plug-in SureFire Plug-in Inclusions

Exclusion

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.16</version> <configuration> <includes> <include>**/Sample.java</include> </includes> </configuration> </plugin>

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.16</version> <configuration> <excludes> <exclude>**/TestA.java</exclude> <exclude>**/TestOne.java</exclude> </excludes> </configuration> </plugin>

Exclusion

SureFire vs. FailSafe – Differences

SureFire plug-in FailSafe plug-in

designed to → run unit tests → run integration tests

used during → the test phase of the build lifecycle to execute the unit tests of an application.

→ the integration-test and verify phases of the build lifecycle to execute the integration tests of an application.

generates reports in 2 different file formats:

Plain text files (*.txt)XML files (*.xml)

default output directory ${basedir}/target/surefire-reports ${basedir}/target/failsafe-reports

run tests using mvn surefire:test mvn failsafe:integration-test

verify integration tests - mvn failsafe:verify

help mvn surefire:help mvn failsafe:help

bound to build phase test pre-integration-testintegration-testpost-integration-testverify

build fails in phase test verify

default wildcard pattern **/Test*.java**/*Test.java**/*TestCase.java

**/IT*.java**/*IT.java**/*ITCase.java

FailSafe and SureFire Maven Plug-ins

NOTE:

If you are using both the SureFire and FailSafe plug-ins, make sure that you use this naming convention to make it easier to identify which tests are being executed by which plug-in.

SureFire and FailSafe configuration – Pom.xml

SureFire FailSafe

Using JUnit

SureFire FailSafe

Running tests in parallel

Sum it up...

To summarize:

Maven is a set of standards

Maven is a repository

Maven is a framework

Maven is software.

Maven is also a vibrant, active open-source community that produces software focused on project management. Using Maven is more than just downloading another JAR file and a set of scripts, it is the adoption of a build life-cycle process that allows you to take your software development to the next level.

Benefits Coherence

Maven projects rely on a standard model/pattern

ReusabilityMaven allows you to reuse components.

Agility Maven makes it easier to create a component and then integrate it into a multi-project build.

MaintainabilityMaven projects are more maintainable because they follow a common model.

References

http://maven.apache.org/

http://maven.apache.org/ref/3.1.0/maven-model/maven.html

maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference

http://maven.apache.org/maven-release/maven-release-plugin/

http://maven.apache.org/plugin-developers/

http://search.maven.org/

BOOKS:

The Maven Cookbook – Sonatype (Edition 4.0) – Tim O’Brien, Stuart McCulloch, Brian Demers

Better Builds with Maven – Vincent Massol, Jason van Zyl, Brett Poter, John Casey, Carlos Sanchez

Maven: The Complete Reference

Apache Maven – User Guide – The Apache Software Foundation

Where to find...

Available plugins: http://mirrors.ibiblio.org/maven2/

SureFire Plug-in details: http://maven.apache.org/surefire/

FailSafe Plug-in details: http://maven.apache.org/surefire/maven-failsafe-plugin/

Repositories :

http://mvnrepository.com/

http://repository.apache.org

Q&A

Thank you for listening!