Maven is a build system that provides:
1) A standard directory structure for projects;
2) A standard build lifecycle of phases like compile, test, package; and
3) The ability to override defaults through plugins.
The document then discusses several key aspects of Maven including:
1) The standard Maven directory structure for source code, resources, and test code;
2) The default Maven lifecycle phases like compile, test, package; and
3) The pom.xml file which is Maven's build specification and configuration file.
2. 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
4. 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
5. 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
7. 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
8. The Default Maven Life Cycle
Build Phase Description
Validate Validate things like the pom.xml files
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 .....
14. Understanding the POM.xml
The <groupId, artifactId, version> tuple forms a
<project>
unique address for a project (and its artifact)
<modelVersion>4.0.0</modelVersion>
•It is aptly known as a Maven coordinate
<!-- The Basics -->
packaging defaults to jar. Other options include pom <groupId>...</groupId>
and war <artifactId>...</artifactId>
<version>...</version>
dependencies refers to a set of dependency <packaging>...</packaging>
elements, each of which define a jar that this projects <dependencies>...</dependencies>
depends on. <parent>...</parent>
<modules>...</modules>
<properties>...</properties>
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>
15. Understanding the POM.xml
To figure out the co-ordinates for a jar when faced with a <project>
ClassNoDefFound exception: <modelVersion>4.0.0</modelVersion>
<dependencies> <!-- The Basics -->
<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>
<modules>...</modules>
<properties>...</properties>
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.
16. Understanding the POM.xml
The parent and modules elements are needed for
<project>
parent-child projects.
<modelVersion>4.0.0</modelVersion>
<!-- The Basics -->
To illustrate, imagine a typical search-indexing project <groupId>...</groupId>
called Foo. <artifactId>...</artifactId>
<version>...</version>
In our Foo project, imagine that we have 3 build artifacts: <packaging>...</packaging>
<dependencies>...</dependencies>
1. An indexer.jar for Indexing code <parent>...</parent>
<modules>...</modules>
2. A search.war for Lucene-based servlet code <properties>...</properties>
3. A ui.war for UI-specific code ......
</project>
One way to structure the code is to create 3 Maven modules
(ui, indexer, and search) under a common parent (Foo)
17. Understanding the POM.xml
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
•
this follows the standard Maven Directory structure
•
it contains a pom.xml for the indexer module
•
a ui subdirectory
•
this follows the standard Maven Directory structure
•
it contains a pom.xml for the ui module
Foo
•
a parent pom.xml file
search
search
pom.xml
indexer
indexer
pom.xml
ui
ui
pom.xml
pom.xml
20. Understanding the POM.xml
<project>
<project> <modelVersion>4.0.0</modelVersion>
<modelVersion>4.0.0</modelVersion>
<!-- The Basics -->
<groupId>com.linkedin</groupId>
<!-- The Basics --> <artifactId>Foo-search</artifactId>
<groupId>com.linkedin</groupId> <version>1.0</version>
<artifactId>Foo</artifactId> <packaging>war</packaging>
<parent>Foo</parent>
<version>1.0</version> pom
<packaging>pom</packaging> <packaging> ......
<modules> type </project>
<module>ui</module> <project>
<modelVersion>4.0.0</modelVersion>
<module>search</module>
<module>indexer</module> 3 <Module> <Parent> Tag <!-- The Basics -->
</modules> Tags in the in child <groupId>com.linkedin</groupId>
...... parent pom.xml <artifactId>Foo-indexer</artifactId>
<version>1.0</version>
</project> pom.xml <packaging>jar</packaging>
<parent>Foo</parent>
......
</project>
search <project>
search <modelVersion>4.0.0</modelVersion>
pom.xml
indexer <!-- The Basics -->
<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
21. Understanding the 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
23. Understanding the POM.xml
<!-- More Project Information -->
<name>...</name>
<description>...</description>
<url>...</url>
These fields are pretty self- <inceptionYear>...</inceptionYear>
explanatory. Good to include, <licenses>...</licenses>
<organization>...</organization>
especially for open-source projects. <developers>...</developers>
<contributors>...</contributors>
25. Understanding the POM.xml
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. <!-- Environment Settings -->
<issueManagement>...</issueManagement>
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>
<prerequisites>...</prerequisites>
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>
<enabled>false</enabled>
</snapshots>
</repository>
26. Understanding the POM.xml
The SCM tag refers to Source Control Management. Maven offers
pretty advanced plug-ins for Git and SVN.
<!-- Environment Settings -->
An example Git SCM tag is shown below. With this enabled, you
<issueManagement>...</issueManagement>
can use powerful features in Maven such as release. “mvn
<ciManagement>...</ciManagement>
release:perform” can release a WAR or JAR to Artifactory or to a
<mailingLists>...</mailingLists>
public Maven repo.
<scm>...</scm>
<prerequisites>...</prerequisites>
Once complete, Maven will automatically up-rev the pom.xml
<repositories>...</repositories>
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>
<profiles>...</profiles>
<connection> </project>
scm:git:git@gitli.corp.linkedin.com:ds-platform/listt.git
</connection>
<url>
scm:git:git@gitli.corp.linkedin.com:ds-platform/listt.git
</url>
<developerConnection>
scm:git:git@gitli.corp.linkedin.com:ds-platform/listt.git
</developerConnection>
</scm>
27. Understanding the POM.xml
The distributionManagement tag is the reverse of the
repositories tag -- it refers to the repository where the build <!-- Environment Settings -->
artifact (i.e. JAR or WAR) will be stored. <issueManagement>...</issueManagement>
<ciManagement>...</ciManagement>
<mailingLists>...</mailingLists>
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>
<enabled>false</enabled>
</snapshots>
</repository>
</distributionManagement >
29. 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!