Hands On with Maven

Hands On With
Maven
Sid Anand (LinkedIn)
July 19, 2012

Overview

Maven is a build system providing
A standard directory structure
A standard build lifecycle
The ability to override default behaviors via plug-ins
Dependency management

The Maven Directory Structure
• A standard directory structure means that the build tool and the user agree on
where different types of files can be found.

• These conventions make coming up to speed on new projects much easier

• Java Source Tree goes under /src/main/java

• Property files goes under /src/main/resources

• Web App files go under /src/main/webapp

• /src/main/webapp/WEB-INF

• /src/main/webapp/WEB-INF/web.xml

• /src/main/webapp/*.jsp

• /src/main/webapp/*.html

The Maven Directory Structure
Path Description

/src/main/java root of source tree (e.g. com/linkedin/...)

/src/main/resources Place configuration & property files here

/src/main/scripts Place scripts here

/src/main/webapp Place web resources here (e.g. .jsp, .html)

root of test source tree (e.g. com/
/src/test/java
linkedin/test/...)

Place configuration & property files
/src/test/resources
needed for tests

Generated during build. Contains all build
/target/
output

The Default Maven Life Cycle
• A default Maven Life Cycle means that you do not need to manually specify build-
steps and chain them together in each project:

• target = “package” dependsOn = “unit-test”

• target = “unit-test” dependsOn = “compile”

• target = “compile” dependsOn = “validate”

• If you have worked with other build-tools (e.g. Make, Scala Build Tool, Ant, etc...),
you will find that you are copying build-specs and specifying this boiler-plate logic
often

• Maven specifies a set of standard build steps and also automatically chains them
together

• This is part of the Maven framework and is not the responsibility of the user to
define

The Default Maven Life Cycle
Build Phase Description

Validate Validate things like the pom.xml ﬁles

Compile sources after resolving and
Compile
downloading dependencies

Test Run Unit Tests

Package Create JAR or WAR

Integration-test Run integration tests against the package

Verify Does the package meet quality criteria?

Install Install in local repository

• Calling “mvn <build phase>” will call all steps before it in order
• e.g. calling “mvn install” will call validate, then compile, then test, then .....

Understanding the POM.xml

The pom.xml ﬁle is Maven’s build spec ﬁle (e.g.
build.xml in Ant)

<project>


<groupId>...</groupId>
<artifactId>...</artifactId>
<packaging>...</packaging>
<parent>...</parent>
<dependencyManagement>...</dependencyManagement>



The elements you will likely use
<build>...</build>
<reporting>...</reporting>

<name>...</name>
<url>...</url>
<inceptionYear>...</inceptionYear>
<licenses>...</licenses>
<developers>...</developers>

<scm>...</scm>
<pluginRepositories>...</pluginRepositories>
<distributionManagement>...</distributionManagement>
</project>

The <groupId, artifactId, version> tuple forms a
<project>
unique address for a project (and its artifact)
•It is aptly known as a Maven coordinate

packaging defaults to jar. Other options include pom <groupId>...</groupId>
and war <artifactId>...</artifactId>
dependencies refers to a set of dependency <packaging>...</packaging>
elements, each of which deﬁne a jar that this projects <dependencies>...</dependencies>
depends on. <parent>...</parent>
For example, if this project required Log4J, you would
specify a dependency element containing a Maven ......
coordinate as shown below: </project>

<dependencies>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
</dependency>
</dependencies>

To ﬁgure out the co-ordinates for a jar when faced with a <project>
ClassNoDefFound exception: <modelVersion>4.0.0</modelVersion>

<dependencies> 
<dependency> <groupId>...</groupId>
<groupId>log4j</groupId> <artifactId>...</artifactId>
<artifactId>log4j</artifactId> <version>...</version>
<version>1.2.17</version> <packaging>...</packaging>
</dependency> <dependencies>...</dependencies>
</dependencies> <parent>...</parent>
1. Try searching on Jarvana ( http://jarvana.com/
......
jarvana/ ). This will give you the names of jars
</project>
containing the Class in question

2. If you know the JAR name, search on Maven Central
for all versions of the JAR. Pick the version you like.

Both Maven Central and Jarvana provide Maven
coordinates.

The parent and modules elements are needed for
<project>
parent-child projects.


To illustrate, imagine a typical search-indexing project <groupId>...</groupId>
called Foo. <artifactId>...</artifactId>
In our Foo project, imagine that we have 3 build artifacts: <packaging>...</packaging>
1. An indexer.jar for Indexing code <parent>...</parent>
2. A search.war for Lucene-based servlet code <properties>...</properties>

3. A ui.war for UI-speciﬁc code ......
</project>

One way to structure the code is to create 3 Maven modules
(ui, indexer, and search) under a common parent (Foo)

Hence, we will have a directory structure as shown below:
a Foo directory containing 3 sub-directories and 1 parent pom.xml:

•
a search sub-directory
•
this follows the standard Maven Directory structure
•
it contains a pom.xml for the search module

•
an indexer sub-directory
•
•
it contains a pom.xml for the indexer module

•
a ui subdirectory
•
•
it contains a pom.xml for the ui module
Foo
•
a parent pom.xml ﬁle
search
search
pom.xml
indexer
indexer
pom.xml
ui
ui
pom.xml

pom.xml

<project>
<project>

 <groupId>com.linkedin</groupId>
<artifactId>Foo-search</artifactId>
<groupId>com.linkedin</groupId> <version>1.0</version>
<artifactId>Foo</artifactId> <packaging>war</packaging>
<version>1.0</version> <parent>Foo</parent>
<packaging>pom</packaging> ......
<modules> </project>
<module>ui</module> <project>
<module>search</module> <modelVersion>4.0.0</modelVersion>
<module>indexer</module> 
</modules> <groupId>com.linkedin</groupId>
...... <artifactId>Foo-indexer</artifactId>
<version>1.0</version>
</project>
<packaging>jar</packaging>
<parent>Foo</parent>

......
</project>
search <project>
search <modelVersion>4.0.0</modelVersion>
pom.xml
indexer 
<groupId>com.linkedin</groupId>
indexer <artifactId>Foo-ui</artifactId>
pom.xml
ui <version>1.0</version>
<packaging>war</packaging>
ui <parent>Foo</parent>
pom.xml
......
</project>
pom.xml

<project>
<project>

 <groupId>com.linkedin</groupId>
<artifactId>Foo-search</artifactId>
<version>1.0</version> <parent>Foo</parent>
<packaging>pom</packaging> ......
<modules> </project>
<module>search</module> <modelVersion>4.0.0</modelVersion>
<module>indexer</module> <Parent> Tag 
</modules> in child <groupId>com.linkedin</groupId>
...... pom.xml <artifactId>Foo-indexer</artifactId>
</project>
<packaging>jar</packaging>

......
search </project>
<project>
pom.xml
pom.xml
pom.xml
......
</project>
pom.xml

<project>
<project> <modelVersion>4.0.0</modelVersion>

 <artifactId>Foo-search</artifactId>
<version>1.0</version> pom
<packaging>pom</packaging> <packaging> ......
<modules> type </project>
<module>search</module>
<module>indexer</module> 3 <Module> <Parent> Tag 
</modules> Tags in the in child <groupId>com.linkedin</groupId>
...... parent pom.xml <artifactId>Foo-indexer</artifactId>
</project> pom.xml <packaging>jar</packaging>

......
</project>
search <project>
pom.xml
pom.xml
pom.xml
......
</project>
pom.xml

Some Useful Information

-- The child POMs inherit the settings in the parent POM.

-- Calling “mvn <command>” on the parent causes all child POMs to be executed

-- Calling “mvn <command>” on a child POM executes on that single child POM, but does
correctly inherit settings from parent POM

Foo
search
search
pom.xml
indexer
indexer
pom.xml
ui
ui
pom.xml

pom.xml

More Project Information (POM)


<name>...</name>
<url>...</url>
These ﬁelds are pretty self- <inceptionYear>...</inceptionYear>
explanatory. Good to include, <licenses>...</licenses>
especially for open-source projects. <developers>...</developers>

The repositories tag refers to refers to repositories that Maven
should refer to when looking for the jars listed in the dependencies
section that we already covered. 
If you do not specify a repositories tag, Maven will look in the default <ciManagement>...</ciManagement>
repository : http://search.maven.org/#browse (a.k.a. http:// <mailingLists>...</mailingLists>
repo.maven.apache.org/maven2/ ) <scm>...</scm>
If you need to access jars from a private repository (e.g. LinkedIn’s <repositories>...</repositories>
Artifactory) and from the default public repository: <pluginRepositories>...</
pluginRepositories>
repositories> <distributionManagement>...</
<repository> distributionManagement>
<id>public-central</id> <profiles>...</profiles>
<url> http://repo.maven.apache.org/maven2/ </url> </project>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<repository>
<id>central-private</id>
<url>
http://artifactory.corp.linkedin.com......./artifactory/release
</url>
<snapshots>
</snapshots>
</repository>

The SCM tag refers to Source Control Management. Maven offers
pretty advanced plug-ins for Git and SVN.
An example Git SCM tag is shown below. With this enabled, you
can use powerful features in Maven such as release. “mvn
release:perform” can release a WAR or JAR to Artifactory or to a
public Maven repo.
<scm>...</scm>
Once complete, Maven will automatically up-rev the pom.xml
version and commit/push the new pom.xml to the Git “origin”
<pluginRepositories>...</
server using the Git connect strings in the SCM tag.
pluginRepositories>
<distributionManagement>...</
distributionManagement>
<scm>
<connection> </project>
scm:git:git@gitli.corp.linkedin.com:ds-platform/listt.git
</connection>
<url>
</url>
<developerConnection>
</developerConnection>
</scm>

The distributionManagement tag is the reverse of the
repositories tag -- it refers to the repository where the build 
artifact (i.e. JAR or WAR) will be stored. <issueManagement>...</issueManagement>
From the previous “mvn release:perform” example, the information <scm>...</scm>
in the distributionManagement tag tells Maven where to post the <prerequisites>...</prerequisites>
jar. <repositories>...</repositories>
<pluginRepositories>...</
<distributionManagement > pluginRepositories>
<repository> <distributionManagement>...</
<id>central-private</id> distributionManagement>
<url> <profiles>...</profiles>
http://artifactory.corp.linkedin.com......./artifactory/ </project>
release
</url>
<snapshots>
</snapshots>
</repository>
</distributionManagement >

Some Useful Commands
All commands must be run in the same directory containing the pom.xml.

• mvn clean, compile --> cleans the project, then compiles it
• mvn clean package --> previous step + create WAR or JAR
• mvn clean install --> previous step + run integration tests and install the WAR or JAR in the
local repository

• mvn release:prepare --> Does the following:
• prompts the user for the version of the jar
• alters the version in the POM.xml (i.e. 1.0-SNAPSHOT --> 1.0)
• runs a clean-compile-test-package cycle
• and generates a release.properties file
• mvn release:perform --> Does the following:
• pushes the JAR/WAR to Artifactory or some public repo
• If successful, bumps up the version in the pom.xml file (i.e. 1.0 --> 1.1-SNAPSHOT)
• You should never need to alter the version in the POM.xml file!

Hands On with Maven

More Related Content

Hands On with Maven