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
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.
Figure 7. A relationship graph
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.
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).
|Forum migration complete By Athen|
|Forum migration update By Athen|
|Heaven By Anonymous|
|The Maven 2 POM demystified By JavaWorld|