Maven Presentation - SureFire vs FailSafe

Summary
Introduction to Maven
Basic Maven Project Structure
Basic Maven POM File
Repositories
Maven Build Profiles
Maven Plug-ins
FailSafe Plug-in
SureFire Plug-in
Conclusion
References
Q&A

Introduction
Maven. . . 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 deﬁned phases in a life-cycle.
Maven is :
A top-level open source Apache Software Foundation project
A popular build tool
A dependency management tool
A release management tool
Project object
model
Dependency
management
model
Project life-cycle and phases
Plug-in Plug-in...
Repositories(localandremote)
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-deﬁned 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:
Builds
Documentation
Reporting
Dependencies
Releases
Distribution

Key Concepts
Project Structure
POM File
Maven Repositories
Dependencies
Life-cycle phases
Maven Profiles
Plug-ins

Project Structure
Directory name Purpose
project 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 Model
Is an XML document
Is Maven’s description of a single project
Contains 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-perfo
description.</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>
<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>
<url
http://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.

POMPOM 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.xml
The 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 profile
mvn groupId:artifactId:goal -P !profile-1,!profile-2
Example:
<profiles>
<profile>
<id>profile-A</id>
<dependencies>
<dependency>
<groupId>com.example</groupId>
<artifactId>dependency</artifactId>
</dependency>
</dependencies>
</profile>
<profile>
<id>profile-B</id>
<dependencies>
<dependency>
<groupId>com.example</groupId>
<artifactId>dependency</artifactId>
</dependency>
</dependencies>
</profile>
</profiles>
Now you can invoke profile-A using the command
mvn -Pprofile-A install

Daily usage
– mvn compile (compile)
– mvn install (compile, test, package, install)
mvn –N install
Take a look at your local repository.
mvn –N
mvn install -Dmaven.test.skip=true
mvn clean
Inspect content of current directory.
mvn compile
Inspect directory target.
mvn test
mvn surefire:test
mvn failsafe:test
Profiles can be selected on the command line:
mvn –P orion2x,resin3x install
What is the difference between “mvn surefire:test” and “mvn test”?

Life-cycle phases
These 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}.m2repositoryorgapachemavenplugins
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>
<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 test
mvn 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>
<artifactId>maven-failsafe-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
Execute tests:
mvn test
mvn failsafe:integration-test
mvn 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>
<configuration>
<includes>
<include>**/Sample.java</include>
</includes>
</configuration>
</plugin>
<plugin>
<configuration>
<excludes>
<exclude>**/OneIT.java</exclude>
<exclude>**/TwoIT.java</exclude>
</excludes>
</configuration>
</plugin>
FailSafe Plug-in SureFire Plug-in
Inclusions
Exclusion
<plugin>
<configuration>
<includes>
<include>**/Sample.java</include>
</includes>
</configuration>
</plugin>
<plugin>
<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-test
integration-test
post-integration-test
verify
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
Reusability
Maven allows you to reuse components.
Agility
Maven makes it easier to create a component and then integrate it into a multi-project build.
Maintainability
Maven 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

Maven Presentation - SureFire vs FailSafe

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (11)

Semelhante a Maven Presentation - SureFire vs FailSafe

Semelhante a Maven Presentation - SureFire vs FailSafe (20)

Maven Presentation - SureFire vs FailSafe