Featured White Papers

• Utilizing Fast Testing to Transform Java Development
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Want to build HTML5 web applications? Check out Kendo UI JSP Server Wrappers!

  Learn More!

• Build modern HTML5 web apps using Java. Try Kendo UI Complete for JSP!

  Learn More!

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

The Maven 2 POM demystified

The evolution of a project model

By Eric Redmond, JavaWorld.com, 05/29/06

Page 4 of 7

 <project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>b</artifactId>
  <version>2</version>
  <packaging>pom</packaging>
  <modules>
    <module>a</module>
  </modules>
</project>

Now if we ran mvn compile in the base directory, you would see the build start with:

 [INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   Unnamed – org.codehaus.mojo:b:pom:2
[INFO]   Unnamed – org.codehaus.mojo:a:jar:2

The Maven lifecycle will now execute up to the lifecycle phase specified in correct order; that is, each artifact is built one at a time, and if one artifact requires another to be built first, it will be.

A note on inheritance vs. aggregation
Inheritance and aggregation create a nice dynamic for controlling builds through a single, high-level POM. You will often see projects that are both parents and multimodules, such as the example above. Their complementariness makes them a natural match. Even the Maven 2 project core runs through a single parent/multimodule POM org.apache.maven:maven, so building a Maven 2 project can be executed by a single command: mvn compile. Although used in conjunction, however, a multimodule and a parent are not one in the same, and should not be confused. A POM project (acting as a parent) may be inherited from, but that parent project does not necessarily aggregate any modules. Conversely, a POM project may aggregate projects that do not inherit from it.

When all four pieces of the equation are put together, hopefully you will see the power of the Maven 2 relationship mechanism, as shown in Figure 7.

Maven gives us a nice framework for relating projects to each other, and through these relationships, we may create plug-ins reusable by any project following Maven's conventions. But the ability to manage project relationships is only a part of the overall Maven equation. The rest of the POM is concerned not with other projects, but with its build settings, its information, and with its environment. With a quick understanding of how projects relate to one another out of the way, let's begin to look at how a POM contains information about the project proper.

Project information

POM information is only as useful as the plug-in that uses it. With this in mind, we will not drill down into the elements of this section in much detail. These elements are mostly self-explanatory and frankly uninteresting beyond their use for reporting plug-ins. The idea that they are used for reporting, however, does not automatically qualify them as build settings. The project information elements are merely used as part of a build process and not actively involved in configuring it. I know—it's a fine line. This batch of information, although not explicitly required to perform most builds, is designed to communicate to other humans some general information about the project. As illustrated in Figure 8, here is where the POM author can define the project's human-readable name, description, homepage (URL), inception year, licenses, the organization in charge of development, as well as the developers and contributors (with a little data about them too).