Post on 17-Jan-2017
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!