Maven is a popular open source build tool for enterprise Java projects, designed to take much of the hard work out of the build process. Maven uses a declarative approach, where the project structure and contents are described, rather then the task-based approach used in Ant or in traditional make files, for example. This helps enforce company-wide development standards and reduces the time needed to write and maintain build scripts.
The declarative, lifecycle-based approach used by Maven 1 is, for many, a radical departure from more traditional build techniques, and Maven 2 goes even further in this regard. In this article, I go through some of the basic principals behind Maven 2 and then step through a working example. Let's start by reviewing the fundamentals of Maven 2.
The project object model
The heart of a Maven 2 project is the project object model (or POM for short). It 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. The POM takes the form of an XML file (
pom.xml), which is placed in your project home directory. A simple pom.xml file is shown here:
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
4.0.0
com.javaworld.hotels
HotelDatabase
war
1.0-SNAPSHOT
Maven Quick Start Archetype
http://maven.apache.org
junit
junit
3.8.1
test
The Maven 2 directory structure
Much of Maven's power comes from the standard practices it encourages. A developer who has previously worked on a Maven project will immediately feel familiar with the structure and organization of a new one. Time need not be wasted reinventing directory structures, conventions, and customized Ant build scripts for each project. Although you can override any particular directory location for your own specific ends, you really should respect the standard Maven 2 directory structure as much as possible, for several reasons:
- It makes your POM file smaller and simpler
- It makes the project easier to understand and makes life easier for the poor guy who must maintain the project when you leave
- It makes it easier to integrate plug-ins
The standard Maven 2 directory structure is illustrated in Figure 1. In the project home directory goes the POM (pom.xml) and two subdirectories: src for all source code and target for generated artifacts.
Figure 1. The standard Maven 2 directory layout
The src directory has a number of subdirectories, each of which has a clearly defined purpose:
- src/main/java: Your Java source code goes here (strangely enough!)
- src/main/resources: Other resources your application needs
- src/main/filters: Resource filters, in the form of properties files, which may be used to define variables only known at runtime
- src/main/config: Configuration files
- src/main/webapp: The Web application directory for a WAR project
- src/test/java: Unit tests
- src/test/resources: Resources to be used for unit tests, but will not be deployed
- src/test/filters: Resources filters to be used for unit tests, but will not be deployed
- src/site: Files used to generate the Maven project Website
Project lifecycles
Project lifecycles are central to Maven 2. Most developers are familiar with the notion of build phases such as compile, test, and deploy. Ant has targets with names like those. In Maven 1, corresponding plug-ins are called directly. To compile Java source code, for instance, the
java plug-in is used:
In Maven 2, this notion is standardized into a set of well-known and well-defined lifecycle phases (see Figure 2). Instead of invoking plug-ins, the Maven 2 developer invokes a lifecycle phase:
$mvn compile.
Figure 2. Maven 2 lifecycle phases
Some of the more useful Maven 2 lifecycle phases are the following:
generate-sources: Generates any extra source code needed for the application, which is generally accomplished using the appropriate plug-ins compile: Compiles the project source code test-compile: Compiles the project unit tests test: Runs the unit tests (typically using JUnit) in the src/test directory package: Packages the compiled code in its distributable format (JAR, WAR, etc.) integration-test: Processes and deploys the package if necessary into an environment where integration tests can be run install: Installs the package into the local repository for use as a dependency in other projects on your local machine deploy: Done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects
Many other lifecycle phases are available. See
Resources for more details.
These phases illustrate the benefits of the recommended practices encouraged by Maven 2: once a developer is familiar with the main Maven 2 lifecycle phases, he should feel at ease with the lifecycle phases of any Maven project.
The lifecycle phase invokes the plug-ins it needs to do the job. Invoking a lifecycle phase automatically invokes any previous lifecycle phases as well. Since the lifecycle phases are limited in number, easy to understand, and well organized, becoming familiar with the lifecycle of a new Maven 2 project is easy.
Transitive dependencies
One of the highlights of Maven 2 is transitive dependency management. If you have ever used a tool like
urpmi on a Linux box, you'll know what transitive dependencies are. With Maven 1, you have to declare each and every JAR that will be needed, directly or indirectly, by your application. For example, can you list the JARs needed by a Hibernate application? With Maven 2, you don't have to. You just tell Maven which libraries
you need, and Maven will take care of the libraries that your libraries need (and so on).
Suppose you want to use Hibernate in your project. You would simply add a new dependency to the
dependencies section in pom.xml, as follows:
hibernate
hibernate
3.0.3
compile
And that's it! You don't have to hunt around to know in which other JARs (and in which versions) you need to run Hibernate 3.0.3; Maven will do it for you!
The XML structure for dependencies in Maven 2 is similar to the one used in Maven 1. The main difference is the
scope tag, which is explained in the following section.
Dependency scopes
In a real-world enterprise application, you may not need to include all the dependencies in the deployed application. Some JARs are needed only for unit testing, while others will be provided at runtime by the application server. Using a technique called
dependency scoping, Maven 2 lets you use certain JARs only when you really need them and excludes them from the classpath when you don't.
