Post on 07-Dec-2014
description
transcript
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