You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maven.apache.org by bu...@apache.org on 2013/04/27 09:29:25 UTC
svn commit: r860084 [20/39] - in /websites/staging/maven/trunk/content: ./
background/ developers/ developers/conventions/ developers/release/
developers/website/ docs/2.0.1/ docs/2.0.10/ docs/2.0.11/ docs/2.0.2/
docs/2.0.3/ docs/2.0.4/ docs/2.0.5/ doc...
Modified: websites/staging/maven/trunk/content/guides/introduction/introduction-to-the-lifecycle.html
==============================================================================
--- websites/staging/maven/trunk/content/guides/introduction/introduction-to-the-lifecycle.html (original)
+++ websites/staging/maven/trunk/content/guides/introduction/introduction-to-the-lifecycle.html Sat Apr 27 07:29:22 2013
@@ -1,6 +1,6 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!--
- | Generated by Apache Maven Doxia at Apr 23, 2013
+ | Generated by Apache Maven Doxia at Apr 27, 2013
| Rendered using Apache Maven Stylus Skin 1.5
-->
<html xmlns="http://www.w3.org/1999/xhtml">
@@ -13,7 +13,7 @@
</style>
<link rel="stylesheet" href="../../css/print.css" type="text/css" media="print" />
<meta name="author" content="Brett Porter" />
- <meta name="Date-Revision-yyyymmdd" content="20130423" />
+ <meta name="Date-Revision-yyyymmdd" content="20130427" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"></script>
@@ -43,7 +43,7 @@
Introduction to the Build Lifecycle
</div>
<div class="xright">
- Last Published: 2013-04-23
+ Last Published: 2013-04-27
</div>
<div class="clear">
<hr/>
@@ -231,7 +231,103 @@
</div>
<div id="bodyColumn">
<div id="contentBox">
- <!-- Copyright 2006 The Apache Software Foundation. --><!-- --><!-- Licensed under the Apache License, Version 2.0 (the "License"); --><!-- you may not use this file except in compliance with the License. --><!-- You may obtain a copy of the License at --><!-- --><!-- http://www.apache.org/licenses/LICENSE-2.0 --><!-- --><!-- Unless required by applicable law or agreed to in writing, software --><!-- distributed under the License is distributed on an "AS IS" BASIS, --><!-- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. --><!-- See the License for the specific language governing permissions and --><!-- limitations under the License. --><!-- NOTE: For help with the syntax of this file, see: --><!-- http://maven.apache.org/doxia/references/apt-format.html --><div class="section"><h2>Introduction to the Build Lifecycle<a name="Introduction_to_the_Build_Lifecycle"></a></h2><div class="section"><h3>Table Of Contents<a name="Table_Of_Contents"><
/a></h3><ul><li><a href="#Build_Lifecycle_Basics">Build Lifecycle Basics</a></li><li><a href="#Setting_Up_Your_Project_to_Use_the_Build_Lifecycle">Setting Up Your Project to Use the Build Lifecycle</a><ul><li><a href="#Packaging">Packaging</a></li><li><a href="#Plugins">Plugins</a></li></ul></li><li><a href="#Lifecycle_Reference">Lifecycle Reference</a></li><li><a href="#Built-in_Lifecycle_Bindings">Built-in Lifecycle Bindings</a></li></ul></div><div class="section"><h3><a name="Build_Lifecycle_Basics">Build Lifecycle Basics</a></h3><p>Maven 2.0 is based around the central concept of a build lifecycle. What this means is that the process for building and distributing a particular artifact (project) is clearly defined.</p><p>For the person building a project, this means that it is only necessary to learn a small set of commands to build any Maven project, and the <a href="./introduction-to-the-pom.html">POM</a> will ensure they get the results they desired.</p><p>There are th
ree built-in build lifecycles: default, clean and site. The default lifecycle handles your project deployment, the clean lifecycle handles project cleaning, while the site lifecycle handles the creation of your project's site documentation.</p><div class="section"><h4><a name="A_Build_Lifecycle_is_Made_Up_of_Phases">A Build Lifecycle is Made Up of Phases</a></h4><p>Each of these build lifecycles is defined by a different list of build phases, wherein a build phase represents a stage in the lifecycle.</p><p>For example, the default lifecycle has the following build phases (for a complete list of the build phases, refer to the <a href="#Lifecycle_Reference">Lifecycle Reference</a>):</p><ul><li><tt>validate</tt> - validate the project is correct and all necessary information is available</li><li><tt>compile</tt> - compile the source code of the project</li><li><tt>test</tt> - test the compiled source code using a suitable unit testing framework. These tests should not require t
he code be packaged or deployed</li><li><tt>package</tt> - take the compiled code and package it in its distributable format, such as a JAR.</li><li><tt>integration-test</tt> - process and deploy the package if necessary into an environment where integration tests can be run</li><li><tt>verify</tt> - run any checks to verify the package is valid and meets quality criteria</li><li><tt>install</tt> - install the package into the local repository, for use as a dependency in other projects locally</li><li><tt>deploy</tt> - done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.</li></ul><p>These build phases (plus the other build phases not shown here) are executed sequentially to complete the default lifecycle. Given the build phases above, this means that when the default lifecycle is used, Maven will first validate the project, then will try to compile the sources, run those against the t
ests, package the binaries (e.g. jar), run integration tests against that package, verify the package, install the verifed package to the local repository, then deploy the installed package in a specified environment.</p><p>To do all those, you only need to call the last build phase to be executed, in this case, <tt>deploy</tt>:</p><div><pre>mvn deploy</pre></div><p>That is because if you call a build phase, it will execute not only that build phase, but also every build phase prior to the called build phase. Thus, doing</p><div><pre>mvn integration-test</pre></div><p>will do every build phase before it (<tt>validate</tt>, <tt>compile</tt>, <tt>package</tt>, etc.), before executing <tt>integration-test</tt>.</p><p>There are more commands that are part of the lifecycle, which will be discussed in the following sections.</p><p>It should also be noted that the same command can be used in a multi-module scenario (i.e. a project with one or more subprojects). For example:</p><div
><pre>mvn clean install</pre></div><p>This command will traverse into all of the subprojects and run <tt>clean</tt>, then <tt>install</tt> (including all of the prior steps).</p><p><i><a href="./introduction-to-the-lifecycle.html">[top]</a>.</i></p></div><div class="section"><h4><a name="A_Build_Phase_is_Made_Up_of_Goals">A Build Phase is Made Up of Goals</a></h4><p>However, even though a build phase is responsible for a specific step in the build lifecycle, the manner in which it carries out those responsibilities may vary. And this is done by declaring the goals bound to those build phases.</p><p>A goal represents a specific task (finer than a build phase) which contributes to the building and managing of a project. It may be bound to zero or more build phases. A goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation. The order of execution depends on the order in which the goal(s) and the build phase(s) are invoked. For exa
mple, consider the command below. The <tt>clean</tt> and <tt>package</tt> arguments are build phases while the <tt>dependency:copy-dependencies</tt> is a goal.</p><div><pre>mvn clean dependency:copy-dependencies package</pre></div><p>If this were to be executed, the <tt>clean</tt> phase will be executed first (meaning it will run all preceeding phases of the clean lifecycle, plus the <tt>clean</tt> phase itself), and then the <tt>dependency:copy-dependencies</tt> goal, before finally executing the <tt>package</tt> phase (and all its preceeding build phases of the default lifecycle).</p><p>Moreover, if a goal is bound to one or more build phases, that goal will be called in all those phases.</p><p>Furthermore, a build phase can also have zero or more goals bound to it. If a build phase has no goals bound to it, that build phase will not execute. But if it has one or more goals bound to it, it will execute all those goals (<i>Note: In Maven 2.0.5 and above, multiple goals boun
d to a phase are executed in the same order as they are declared in the POM, however multiple instances of the same plugin are not supported. Multiple instances of the same plugin are grouped to execute together and ordered in Maven 2.0.11 and above</i>).</p><p><i><a href="./introduction-to-the-lifecycle.html">[top]</a>.</i></p></div></div><div class="section"><h3><a name="Setting_Up_Your_Project_to_Use_the_Build_Lifecycle">Setting Up Your Project to Use the Build Lifecycle</a></h3><p>The build lifecycle is simple enough to use, but when you are constructing a Maven build for a project, how do you go about assigning tasks to each of those build phases?</p><div class="section"><h4><a name="Packaging">Packaging</a></h4><p>The first, and most common way, is to set the packaging for your project via the equally named POM element <tt><packaging></tt>. Some of the valid packaging values are <tt>jar</tt>, <tt>war</tt>, <tt>ear</tt> and <tt>pom</tt>. If no packaging value has
been specified, it will default to <tt>jar</tt>.</p><p>Each packaging contains a list of goals to bind to a particular phase. For example, the <tt>jar</tt> packaging will bind the following goals to build phases of the default lifecycle.</p><table border="1" class="bodyTable"><tr class="a"><td align="left"><tt>process-resources</tt></td><td align="left"><tt>resources:resources</tt></td></tr><tr class="b"><td align="left"><tt>compile</tt></td><td align="left"><tt>compiler:compile</tt></td></tr><tr class="a"><td align="left"><tt>process-test-resources</tt></td><td align="left"><tt>resources:testResources</tt></td></tr><tr class="b"><td align="left"><tt>test-compile</tt></td><td align="left"><tt>compiler:testCompile</tt></td></tr><tr class="a"><td align="left"><tt>test</tt></td><td align="left"><tt>surefire:test</tt></td></tr><tr class="b"><td align="left"><tt>package</tt></td><td align="left"><tt>jar:jar</tt></td></tr><tr class="a"><td align="left"><tt>install</tt></td><td ali
gn="left"><tt>install:install</tt></td></tr><tr class="b"><td align="left"><tt>deploy</tt></td><td align="left"><tt>deploy:deploy</tt></td></tr></table><p>This is an almost standard set of bindings; however, some packagings handle them differently. For example, a project that is purely metadata (packaging value is <tt>pom</tt>) only binds goals to the <tt>install</tt> and <tt>deploy</tt> phases (for a complete list of goal-to-build-phase bindings of some of the packaging types, refer to the <a href="#Lifecycle_Reference">Lifecycle Reference</a>).</p><p>Note that for some packaging types to be available, you may also need to include a particular plugin in the <tt><build></tt> section of your POM and specify <tt><extensions>true</extensions></tt> for that plugin. One example of a plugin that requires this is the Plexus plugin, which provides a <tt>plexus-application</tt> and <tt>plexus-service</tt> packaging.</p><p><i><a href="./introduction-to-the-lifecycle.
html">[top]</a>.</i></p></div><div class="section"><h4><a name="Plugins">Plugins</a></h4><p>The second way to add goals to phases is to configure plugins in your project. Plugins are artifacts that provide goals to Maven. Furthermore, a plugin may have one or more goals wherein each goal represents a capability of that plugin. For example, the Compiler plugin has two goals: <tt>compile</tt> and <tt>testCompile</tt>. The former compiles the source code of your main code, while the later compiles the source code of your test code.</p><p>As you will see in the later sections, plugins can contain information that indicates which lifecycle phase to bind a goal to. Note that adding the plugin on its own is not enough information - you must also specify the goals you want to run as part of your build.</p><p>The goals that are configured will be added to the goals already bound to the lifecycle from the packaging selected. If more than one goal is bound to a particular phase, the or
der used is that those from the packaging are executed first, followed by those configured in the POM. Note that you can use the <tt><executions></tt> element to gain more control over the order of particular goals.</p><p>For example, the Modello plugin binds by default its goal <tt>modello:java</tt> to the <tt>generate-sources</tt> phase (Note: The <tt>modello:java</tt> goal generates Java source codes). So to use the Modello plugin and have it generate sources from a model and incorporate that into the build, you would add the following to your POM in the <tt><plugins></tt> section of <tt><build></tt>:</p><div><pre>...
+ <!-- Copyright 2006 The Apache Software Foundation. --><!-- --><!-- Licensed under the Apache License, Version 2.0 (the "License"); --><!-- you may not use this file except in compliance with the License. --><!-- You may obtain a copy of the License at --><!-- --><!-- http://www.apache.org/licenses/LICENSE-2.0 --><!-- --><!-- Unless required by applicable law or agreed to in writing, software --><!-- distributed under the License is distributed on an "AS IS" BASIS, --><!-- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. --><!-- See the License for the specific language governing permissions and --><!-- limitations under the License. --><!-- NOTE: For help with the syntax of this file, see: --><!-- http://maven.apache.org/doxia/references/apt-format.html --><div class="section">
+<h2>Introduction to the Build Lifecycle<a name="Introduction_to_the_Build_Lifecycle"></a></h2>
+<div class="section">
+<h3>Table Of Contents<a name="Table_Of_Contents"></a></h3>
+<ul>
+<li><a href="#Build_Lifecycle_Basics">Build Lifecycle Basics</a></li>
+<li><a href="#Setting_Up_Your_Project_to_Use_the_Build_Lifecycle">Setting Up Your Project to Use the Build Lifecycle</a>
+<ul>
+<li><a href="#Packaging">Packaging</a></li>
+<li><a href="#Plugins">Plugins</a></li></ul></li>
+<li><a href="#Lifecycle_Reference">Lifecycle Reference</a></li>
+<li><a href="#Built-in_Lifecycle_Bindings">Built-in Lifecycle Bindings</a></li></ul></div>
+<div class="section">
+<h3><a name="Build_Lifecycle_Basics">Build Lifecycle Basics</a></h3>
+<p>Maven 2.0 is based around the central concept of a build lifecycle. What this means is that the process for building and distributing a particular artifact (project) is clearly defined.</p>
+<p>For the person building a project, this means that it is only necessary to learn a small set of commands to build any Maven project, and the <a href="./introduction-to-the-pom.html">POM</a> will ensure they get the results they desired.</p>
+<p>There are three built-in build lifecycles: default, clean and site. The default lifecycle handles your project deployment, the clean lifecycle handles project cleaning, while the site lifecycle handles the creation of your project's site documentation.</p>
+<div class="section">
+<h4><a name="A_Build_Lifecycle_is_Made_Up_of_Phases">A Build Lifecycle is Made Up of Phases</a></h4>
+<p>Each of these build lifecycles is defined by a different list of build phases, wherein a build phase represents a stage in the lifecycle.</p>
+<p>For example, the default lifecycle has the following build phases (for a complete list of the build phases, refer to the <a href="#Lifecycle_Reference">Lifecycle Reference</a>):</p>
+<ul>
+<li><tt>validate</tt> - validate the project is correct and all necessary information is available</li>
+<li><tt>compile</tt> - compile the source code of the project</li>
+<li><tt>test</tt> - test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed</li>
+<li><tt>package</tt> - take the compiled code and package it in its distributable format, such as a JAR.</li>
+<li><tt>integration-test</tt> - process and deploy the package if necessary into an environment where integration tests can be run</li>
+<li><tt>verify</tt> - run any checks to verify the package is valid and meets quality criteria</li>
+<li><tt>install</tt> - install the package into the local repository, for use as a dependency in other projects locally</li>
+<li><tt>deploy</tt> - done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.</li></ul>
+<p>These build phases (plus the other build phases not shown here) are executed sequentially to complete the default lifecycle. Given the build phases above, this means that when the default lifecycle is used, Maven will first validate the project, then will try to compile the sources, run those against the tests, package the binaries (e.g. jar), run integration tests against that package, verify the package, install the verifed package to the local repository, then deploy the installed package in a specified environment.</p>
+<p>To do all those, you only need to call the last build phase to be executed, in this case, <tt>deploy</tt>:</p>
+<div>
+<pre>mvn deploy</pre></div>
+<p>That is because if you call a build phase, it will execute not only that build phase, but also every build phase prior to the called build phase. Thus, doing</p>
+<div>
+<pre>mvn integration-test</pre></div>
+<p>will do every build phase before it (<tt>validate</tt>, <tt>compile</tt>, <tt>package</tt>, etc.), before executing <tt>integration-test</tt>.</p>
+<p>There are more commands that are part of the lifecycle, which will be discussed in the following sections.</p>
+<p>It should also be noted that the same command can be used in a multi-module scenario (i.e. a project with one or more subprojects). For example:</p>
+<div>
+<pre>mvn clean install</pre></div>
+<p>This command will traverse into all of the subprojects and run <tt>clean</tt>, then <tt>install</tt> (including all of the prior steps).</p>
+<p><i><a href="./introduction-to-the-lifecycle.html">[top]</a>.</i></p></div>
+<div class="section">
+<h4><a name="A_Build_Phase_is_Made_Up_of_Goals">A Build Phase is Made Up of Goals</a></h4>
+<p>However, even though a build phase is responsible for a specific step in the build lifecycle, the manner in which it carries out those responsibilities may vary. And this is done by declaring the goals bound to those build phases.</p>
+<p>A goal represents a specific task (finer than a build phase) which contributes to the building and managing of a project. It may be bound to zero or more build phases. A goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation. The order of execution depends on the order in which the goal(s) and the build phase(s) are invoked. For example, consider the command below. The <tt>clean</tt> and <tt>package</tt> arguments are build phases while the <tt>dependency:copy-dependencies</tt> is a goal.</p>
+<div>
+<pre>mvn clean dependency:copy-dependencies package</pre></div>
+<p>If this were to be executed, the <tt>clean</tt> phase will be executed first (meaning it will run all preceeding phases of the clean lifecycle, plus the <tt>clean</tt> phase itself), and then the <tt>dependency:copy-dependencies</tt> goal, before finally executing the <tt>package</tt> phase (and all its preceeding build phases of the default lifecycle).</p>
+<p>Moreover, if a goal is bound to one or more build phases, that goal will be called in all those phases.</p>
+<p>Furthermore, a build phase can also have zero or more goals bound to it. If a build phase has no goals bound to it, that build phase will not execute. But if it has one or more goals bound to it, it will execute all those goals (<i>Note: In Maven 2.0.5 and above, multiple goals bound to a phase are executed in the same order as they are declared in the POM, however multiple instances of the same plugin are not supported. Multiple instances of the same plugin are grouped to execute together and ordered in Maven 2.0.11 and above</i>).</p>
+<p><i><a href="./introduction-to-the-lifecycle.html">[top]</a>.</i></p></div></div>
+<div class="section">
+<h3><a name="Setting_Up_Your_Project_to_Use_the_Build_Lifecycle">Setting Up Your Project to Use the Build Lifecycle</a></h3>
+<p>The build lifecycle is simple enough to use, but when you are constructing a Maven build for a project, how do you go about assigning tasks to each of those build phases?</p>
+<div class="section">
+<h4><a name="Packaging">Packaging</a></h4>
+<p>The first, and most common way, is to set the packaging for your project via the equally named POM element <tt><packaging></tt>. Some of the valid packaging values are <tt>jar</tt>, <tt>war</tt>, <tt>ear</tt> and <tt>pom</tt>. If no packaging value has been specified, it will default to <tt>jar</tt>.</p>
+<p>Each packaging contains a list of goals to bind to a particular phase. For example, the <tt>jar</tt> packaging will bind the following goals to build phases of the default lifecycle.</p>
+<table border="1" class="bodyTable">
+<tr class="a">
+<td align="left"><tt>process-resources</tt></td>
+<td align="left"><tt>resources:resources</tt></td></tr>
+<tr class="b">
+<td align="left"><tt>compile</tt></td>
+<td align="left"><tt>compiler:compile</tt></td></tr>
+<tr class="a">
+<td align="left"><tt>process-test-resources</tt></td>
+<td align="left"><tt>resources:testResources</tt></td></tr>
+<tr class="b">
+<td align="left"><tt>test-compile</tt></td>
+<td align="left"><tt>compiler:testCompile</tt></td></tr>
+<tr class="a">
+<td align="left"><tt>test</tt></td>
+<td align="left"><tt>surefire:test</tt></td></tr>
+<tr class="b">
+<td align="left"><tt>package</tt></td>
+<td align="left"><tt>jar:jar</tt></td></tr>
+<tr class="a">
+<td align="left"><tt>install</tt></td>
+<td align="left"><tt>install:install</tt></td></tr>
+<tr class="b">
+<td align="left"><tt>deploy</tt></td>
+<td align="left"><tt>deploy:deploy</tt></td></tr></table>
+<p>This is an almost standard set of bindings; however, some packagings handle them differently. For example, a project that is purely metadata (packaging value is <tt>pom</tt>) only binds goals to the <tt>install</tt> and <tt>deploy</tt> phases (for a complete list of goal-to-build-phase bindings of some of the packaging types, refer to the <a href="#Lifecycle_Reference">Lifecycle Reference</a>).</p>
+<p>Note that for some packaging types to be available, you may also need to include a particular plugin in the <tt><build></tt> section of your POM and specify <tt><extensions>true</extensions></tt> for that plugin. One example of a plugin that requires this is the Plexus plugin, which provides a <tt>plexus-application</tt> and <tt>plexus-service</tt> packaging.</p>
+<p><i><a href="./introduction-to-the-lifecycle.html">[top]</a>.</i></p></div>
+<div class="section">
+<h4><a name="Plugins">Plugins</a></h4>
+<p>The second way to add goals to phases is to configure plugins in your project. Plugins are artifacts that provide goals to Maven. Furthermore, a plugin may have one or more goals wherein each goal represents a capability of that plugin. For example, the Compiler plugin has two goals: <tt>compile</tt> and <tt>testCompile</tt>. The former compiles the source code of your main code, while the later compiles the source code of your test code.</p>
+<p>As you will see in the later sections, plugins can contain information that indicates which lifecycle phase to bind a goal to. Note that adding the plugin on its own is not enough information - you must also specify the goals you want to run as part of your build.</p>
+<p>The goals that are configured will be added to the goals already bound to the lifecycle from the packaging selected. If more than one goal is bound to a particular phase, the order used is that those from the packaging are executed first, followed by those configured in the POM. Note that you can use the <tt><executions></tt> element to gain more control over the order of particular goals.</p>
+<p>For example, the Modello plugin binds by default its goal <tt>modello:java</tt> to the <tt>generate-sources</tt> phase (Note: The <tt>modello:java</tt> goal generates Java source codes). So to use the Modello plugin and have it generate sources from a model and incorporate that into the build, you would add the following to your POM in the <tt><plugins></tt> section of <tt><build></tt>:</p>
+<div>
+<pre>...
<plugin>
<groupId>org.codehaus.modello</groupId>
<artifactId>modello-maven-plugin</artifactId>
@@ -250,7 +346,12 @@
</execution>
</executions>
</plugin>
-...</pre></div><p>You might be wondering why that <tt><executions></tt> element is there. That is so that you can run the same goal multiple times with different configuration if needed. Separate executions can also be given an ID so that during inheritance or the application of profiles you can control whether goal configuration is merged or turned into an additional execution.</p><p>When multiple executions are given that match a particular phase, they are executed in the order specified in the POM, with inherited executions running first.</p><p>Now, in the case of <tt>modello:java</tt>, it only makes sense in the <tt>generate-sources</tt> phase. But some goals can be used in more than one phase, and there may not be a sensible default. For those, you can specify the phase yourself. For example, let's say you have a goal <tt>display:time</tt> that echos the current time to the commandline, and you want it to run in the <tt>process-test-resources</tt> phase to indicat
e when the tests were started. This would be configured like so:</p><div><pre>...
+...</pre></div>
+<p>You might be wondering why that <tt><executions></tt> element is there. That is so that you can run the same goal multiple times with different configuration if needed. Separate executions can also be given an ID so that during inheritance or the application of profiles you can control whether goal configuration is merged or turned into an additional execution.</p>
+<p>When multiple executions are given that match a particular phase, they are executed in the order specified in the POM, with inherited executions running first.</p>
+<p>Now, in the case of <tt>modello:java</tt>, it only makes sense in the <tt>generate-sources</tt> phase. But some goals can be used in more than one phase, and there may not be a sensible default. For those, you can specify the phase yourself. For example, let's say you have a goal <tt>display:time</tt> that echos the current time to the commandline, and you want it to run in the <tt>process-test-resources</tt> phase to indicate when the tests were started. This would be configured like so:</p>
+<div>
+<pre>...
<plugin>
<groupId>com.mycompany.example</groupId>
<artifactId>display-maven-plugin</artifactId>
@@ -264,7 +365,217 @@
</execution>
</executions>
</plugin>
-...</pre></div><p><i><a href="./introduction-to-the-lifecycle.html">[top]</a>.</i></p></div></div><div class="section"><h3><a name="Lifecycle_Reference">Lifecycle Reference</a></h3><p>The following lists all build phases of the default, clean and site lifecycle, which are executed in the order given up to the point of the one specified.</p><p><b>Clean Lifecycle</b></p><table border="1" class="bodyTable"><tr class="a"><td align="left"><tt>pre-clean</tt></td><td align="left">executes processes needed prior to the actual project cleaning</td></tr><tr class="b"><td align="left"><tt>clean</tt></td><td align="left">remove all files generated by the previous build</td></tr><tr class="a"><td align="left"><tt>post-clean</tt></td><td align="left">executes processes needed to finalize the project cleaning</td></tr></table><p><b>Default Lifecycle</b></p><table border="1" class="bodyTable"><tr class="a"><td align="left"><tt>validate</tt></td><td align="left">validate the project is corre
ct and all necessary information is available.</td></tr><tr class="b"><td align="left"><tt>initialize</tt></td><td align="left">initialize build state, e.g. set properties or create directories.</td></tr><tr class="a"><td align="left"><tt>generate-sources</tt></td><td align="left">generate any source code for inclusion in compilation.</td></tr><tr class="b"><td align="left"><tt>process-sources</tt></td><td align="left">process the source code, for example to filter any values.</td></tr><tr class="a"><td align="left"><tt>generate-resources</tt></td><td align="left">generate resources for inclusion in the package.</td></tr><tr class="b"><td align="left"><tt>process-resources</tt></td><td align="left">copy and process the resources into the destination directory, ready for packaging.</td></tr><tr class="a"><td align="left"><tt>compile</tt></td><td align="left">compile the source code of the project.</td></tr><tr class="b"><td align="left"><tt>process-classes</tt></td><td align=
"left">post-process the generated files from compilation, for example to do bytecode enhancement on Java classes.</td></tr><tr class="a"><td align="left"><tt>generate-test-sources</tt></td><td align="left">generate any test source code for inclusion in compilation.</td></tr><tr class="b"><td align="left"><tt>process-test-sources</tt></td><td align="left">process the test source code, for example to filter any values.</td></tr><tr class="a"><td align="left"><tt>generate-test-resources</tt></td><td align="left">create resources for testing.</td></tr><tr class="b"><td align="left"><tt>process-test-resources</tt></td><td align="left">copy and process the resources into the test destination directory.</td></tr><tr class="a"><td align="left"><tt>test-compile</tt></td><td align="left">compile the test source code into the test destination directory</td></tr><tr class="b"><td align="left"><tt>process-test-classes</tt></td><td align="left">post-process the generated files from test c
ompilation, for example to do bytecode enhancement on Java classes. For Maven 2.0.5 and above.</td></tr><tr class="a"><td align="left"><tt>test</tt></td><td align="left">run tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed.</td></tr><tr class="b"><td align="left"><tt>prepare-package</tt></td><td align="left">perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, processed version of the package. (Maven 2.1 and above)</td></tr><tr class="a"><td align="left"><tt>package</tt></td><td align="left">take the compiled code and package it in its distributable format, such as a JAR.</td></tr><tr class="b"><td align="left"><tt>pre-integration-test</tt></td><td align="left">perform actions required before integration tests are executed. This may involve things such as setting up the required environment.</td></tr><tr class="a"><td align="left"><tt>integration-tes
t</tt></td><td align="left">process and deploy the package if necessary into an environment where integration tests can be run.</td></tr><tr class="b"><td align="left"><tt>post-integration-test</tt></td><td align="left">perform actions required after integration tests have been executed. This may including cleaning up the environment.</td></tr><tr class="a"><td align="left"><tt>verify</tt></td><td align="left">run any checks to verify the package is valid and meets quality criteria.</td></tr><tr class="b"><td align="left"><tt>install</tt></td><td align="left">install the package into the local repository, for use as a dependency in other projects locally.</td></tr><tr class="a"><td align="left"><tt>deploy</tt></td><td align="left">done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.</td></tr></table><p><b>Site Lifecycle</b></p><table border="1" class="bodyTable"><tr class="a"><td alig
n="left">pre-site</td><td align="left">executes processes needed prior to the actual project site generation</td></tr><tr class="b"><td align="left">site</td><td align="left">generates the project's site documentation</td></tr><tr class="a"><td align="left">post-site</td><td align="left">executes processes needed to finalize the site generation, and to prepare for site deployment</td></tr><tr class="b"><td align="left">site-deploy</td><td align="left">deploys the generated site documentation to the specified web server</td></tr></table><p><i><a href="./introduction-to-the-lifecycle.html">[top]</a>.</i></p></div><div class="section"><h3><a name="Built-in_Lifecycle_Bindings">Built-in Lifecycle Bindings</a></h3><p>Some phases have goals binded to them by default. And for the default lifecycle, these bindings depend on the packaging value. Here are some of the goal-to-build-phase bindings.</p><div class="section"><h4>Clean Lifecycle Bindings<a name="Clean_Lifecycle_Bindings"></a
></h4><table border="1" class="bodyTable"><tr class="a"><td align="left"><tt>clean</tt></td><td align="left"><tt>clean:clean</tt></td></tr></table></div><div class="section"><h4>Default Lifecycle Bindings - Packaging <tt>ejb</tt> / <tt>ejb3</tt> / <tt>jar</tt> / <tt>par</tt> / <tt>rar</tt> / <tt>war</tt><a name="Default_Lifecycle_Bindings_-_Packaging_ejb__ejb3__jar__par__rar__war"></a></h4><table border="1" class="bodyTable"><tr class="a"><td align="left"><tt>process-resources</tt></td><td align="left"><tt>resources:resources</tt></td></tr><tr class="b"><td align="left"><tt>compile</tt></td><td align="left"><tt>compiler:compile</tt></td></tr><tr class="a"><td align="left"><tt>process-test-resources</tt></td><td align="left"><tt>resources:testResources</tt></td></tr><tr class="b"><td align="left"><tt>test-compile</tt></td><td align="left"><tt>compiler:testCompile</tt></td></tr><tr class="a"><td align="left"><tt>test</tt></td><td align="left"><tt>surefire:test</tt></td></tr><t
r class="b"><td align="left"><tt>package</tt></td><td align="left"><tt>ejb:ejb</tt> <i>or</i> <tt>ejb3:ejb3</tt> <i>or</i> <tt>jar:jar</tt> <i>or</i> <tt>par:par</tt> <i>or</i> <tt>rar:rar</tt> <i>or</i> <tt>war:war</tt></td></tr><tr class="a"><td align="left"><tt>install</tt></td><td align="left"><tt>install:install</tt></td></tr><tr class="b"><td align="left"><tt>deploy</tt></td><td align="left"><tt>deploy:deploy</tt></td></tr></table></div><div class="section"><h4>Default Lifecycle Bindings - Packaging <tt>ear</tt><a name="Default_Lifecycle_Bindings_-_Packaging_ear"></a></h4><table border="1" class="bodyTable"><tr class="a"><td align="left"><tt>generate-resources</tt></td><td align="left"><tt>ear:generateApplicationXml</tt></td></tr><tr class="b"><td align="left"><tt>process-resources</tt></td><td align="left"><tt>resources:resources</tt></td></tr><tr class="a"><td align="left"><tt>package</tt></td><td align="left"><tt>ear:ear</tt></td></tr><tr class="b"><td align="left">
<tt>install</tt></td><td align="left"><tt>install:install</tt></td></tr><tr class="a"><td align="left"><tt>deploy</tt></td><td align="left"><tt>deploy:deploy</tt></td></tr></table></div><div class="section"><h4>Default Lifecycle Bindings - Packaging <tt>maven-plugin</tt><a name="Default_Lifecycle_Bindings_-_Packaging_maven-plugin"></a></h4><table border="1" class="bodyTable"><tr class="a"><td align="left"><tt>generate-resources</tt></td><td align="left"><tt>plugin:descriptor</tt></td></tr><tr class="b"><td align="left"><tt>process-resources</tt></td><td align="left"><tt>resources:resources</tt></td></tr><tr class="a"><td align="left"><tt>compile</tt></td><td align="left"><tt>compiler:compile</tt></td></tr><tr class="b"><td align="left"><tt>process-test-resources</tt></td><td align="left"><tt>resources:testResources</tt></td></tr><tr class="a"><td align="left"><tt>test-compile</tt></td><td align="left"><tt>compiler:testCompile</tt></td></tr><tr class="b"><td align="left"><tt>
test</tt></td><td align="left"><tt>surefire:test</tt></td></tr><tr class="a"><td align="left"><tt>package</tt></td><td align="left"><tt>jar:jar</tt> <i>and</i> <tt>plugin:addPluginArtifactMetadata</tt></td></tr><tr class="b"><td align="left"><tt>install</tt></td><td align="left"><tt>install:install</tt> <i>and</i> <tt>plugin:updateRegistry</tt></td></tr><tr class="a"><td align="left"><tt>deploy</tt></td><td align="left"><tt>deploy:deploy</tt></td></tr></table></div><div class="section"><h4>Default Lifecycle Bindings - Packaging <tt>pom</tt><a name="Default_Lifecycle_Bindings_-_Packaging_pom"></a></h4><table border="1" class="bodyTable"><tr class="a"><td align="left"><tt>package</tt></td><td align="left"><tt>site:attach-descriptor</tt></td></tr><tr class="b"><td align="left"><tt>install</tt></td><td align="left"><tt>install:install</tt></td></tr><tr class="a"><td align="left"><tt>deploy</tt></td><td align="left"><tt>deploy:deploy</tt></td></tr></table></div><div class="sectio
n"><h4>Site Lifecycle Bindings<a name="Site_Lifecycle_Bindings"></a></h4><table border="1" class="bodyTable"><tr class="a"><td align="left"><tt>site</tt></td><td align="left"><tt>site:site</tt></td></tr><tr class="b"><td align="left"><tt>site-deploy</tt></td><td align="left"><tt>site:deploy</tt></td></tr></table></div><div class="section"><h4>References<a name="References"></a></h4><p>The full Maven lifecycle is defined by the file <tt>components.xml</tt> in the module <tt>maven-core</tt> and viewable from SVN in the branches for <a class="externalLink" href="http://svn.apache.org/repos/asf/maven/maven-2/tags/maven-2.2.0/maven-core/src/main/resources/META-INF/plexus/components.xml">Maven 2.2.0</a> and <a class="externalLink" href="http://svn.apache.org/repos/asf/maven/maven-3/trunk/maven-core/src/main/resources/META-INF/plexus/components.xml">Maven 3.0.x</a>.</p><p><i><a href="./introduction-to-the-lifecycle.html">[top]</a>.</i></p></div></div></div>
+...</pre></div>
+<p><i><a href="./introduction-to-the-lifecycle.html">[top]</a>.</i></p></div></div>
+<div class="section">
+<h3><a name="Lifecycle_Reference">Lifecycle Reference</a></h3>
+<p>The following lists all build phases of the default, clean and site lifecycle, which are executed in the order given up to the point of the one specified.</p>
+<p><b>Clean Lifecycle</b></p>
+<table border="1" class="bodyTable">
+<tr class="a">
+<td align="left"><tt>pre-clean</tt></td>
+<td align="left">executes processes needed prior to the actual project cleaning</td></tr>
+<tr class="b">
+<td align="left"><tt>clean</tt></td>
+<td align="left">remove all files generated by the previous build</td></tr>
+<tr class="a">
+<td align="left"><tt>post-clean</tt></td>
+<td align="left">executes processes needed to finalize the project cleaning</td></tr></table>
+<p><b>Default Lifecycle</b></p>
+<table border="1" class="bodyTable">
+<tr class="a">
+<td align="left"><tt>validate</tt></td>
+<td align="left">validate the project is correct and all necessary information is available.</td></tr>
+<tr class="b">
+<td align="left"><tt>initialize</tt></td>
+<td align="left">initialize build state, e.g. set properties or create directories.</td></tr>
+<tr class="a">
+<td align="left"><tt>generate-sources</tt></td>
+<td align="left">generate any source code for inclusion in compilation.</td></tr>
+<tr class="b">
+<td align="left"><tt>process-sources</tt></td>
+<td align="left">process the source code, for example to filter any values.</td></tr>
+<tr class="a">
+<td align="left"><tt>generate-resources</tt></td>
+<td align="left">generate resources for inclusion in the package.</td></tr>
+<tr class="b">
+<td align="left"><tt>process-resources</tt></td>
+<td align="left">copy and process the resources into the destination directory, ready for packaging.</td></tr>
+<tr class="a">
+<td align="left"><tt>compile</tt></td>
+<td align="left">compile the source code of the project.</td></tr>
+<tr class="b">
+<td align="left"><tt>process-classes</tt></td>
+<td align="left">post-process the generated files from compilation, for example to do bytecode enhancement on Java classes.</td></tr>
+<tr class="a">
+<td align="left"><tt>generate-test-sources</tt></td>
+<td align="left">generate any test source code for inclusion in compilation.</td></tr>
+<tr class="b">
+<td align="left"><tt>process-test-sources</tt></td>
+<td align="left">process the test source code, for example to filter any values.</td></tr>
+<tr class="a">
+<td align="left"><tt>generate-test-resources</tt></td>
+<td align="left">create resources for testing.</td></tr>
+<tr class="b">
+<td align="left"><tt>process-test-resources</tt></td>
+<td align="left">copy and process the resources into the test destination directory.</td></tr>
+<tr class="a">
+<td align="left"><tt>test-compile</tt></td>
+<td align="left">compile the test source code into the test destination directory</td></tr>
+<tr class="b">
+<td align="left"><tt>process-test-classes</tt></td>
+<td align="left">post-process the generated files from test compilation, for example to do bytecode enhancement on Java classes. For Maven 2.0.5 and above.</td></tr>
+<tr class="a">
+<td align="left"><tt>test</tt></td>
+<td align="left">run tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed.</td></tr>
+<tr class="b">
+<td align="left"><tt>prepare-package</tt></td>
+<td align="left">perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, processed version of the package. (Maven 2.1 and above)</td></tr>
+<tr class="a">
+<td align="left"><tt>package</tt></td>
+<td align="left">take the compiled code and package it in its distributable format, such as a JAR.</td></tr>
+<tr class="b">
+<td align="left"><tt>pre-integration-test</tt></td>
+<td align="left">perform actions required before integration tests are executed. This may involve things such as setting up the required environment.</td></tr>
+<tr class="a">
+<td align="left"><tt>integration-test</tt></td>
+<td align="left">process and deploy the package if necessary into an environment where integration tests can be run.</td></tr>
+<tr class="b">
+<td align="left"><tt>post-integration-test</tt></td>
+<td align="left">perform actions required after integration tests have been executed. This may including cleaning up the environment.</td></tr>
+<tr class="a">
+<td align="left"><tt>verify</tt></td>
+<td align="left">run any checks to verify the package is valid and meets quality criteria.</td></tr>
+<tr class="b">
+<td align="left"><tt>install</tt></td>
+<td align="left">install the package into the local repository, for use as a dependency in other projects locally.</td></tr>
+<tr class="a">
+<td align="left"><tt>deploy</tt></td>
+<td align="left">done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.</td></tr></table>
+<p><b>Site Lifecycle</b></p>
+<table border="1" class="bodyTable">
+<tr class="a">
+<td align="left">pre-site</td>
+<td align="left">executes processes needed prior to the actual project site generation</td></tr>
+<tr class="b">
+<td align="left">site</td>
+<td align="left">generates the project's site documentation</td></tr>
+<tr class="a">
+<td align="left">post-site</td>
+<td align="left">executes processes needed to finalize the site generation, and to prepare for site deployment</td></tr>
+<tr class="b">
+<td align="left">site-deploy</td>
+<td align="left">deploys the generated site documentation to the specified web server</td></tr></table>
+<p><i><a href="./introduction-to-the-lifecycle.html">[top]</a>.</i></p></div>
+<div class="section">
+<h3><a name="Built-in_Lifecycle_Bindings">Built-in Lifecycle Bindings</a></h3>
+<p>Some phases have goals binded to them by default. And for the default lifecycle, these bindings depend on the packaging value. Here are some of the goal-to-build-phase bindings.</p>
+<div class="section">
+<h4>Clean Lifecycle Bindings<a name="Clean_Lifecycle_Bindings"></a></h4>
+<table border="1" class="bodyTable">
+<tr class="a">
+<td align="left"><tt>clean</tt></td>
+<td align="left"><tt>clean:clean</tt></td></tr></table></div>
+<div class="section">
+<h4>Default Lifecycle Bindings - Packaging <tt>ejb</tt> / <tt>ejb3</tt> / <tt>jar</tt> / <tt>par</tt> / <tt>rar</tt> / <tt>war</tt><a name="Default_Lifecycle_Bindings_-_Packaging_ejb__ejb3__jar__par__rar__war"></a></h4>
+<table border="1" class="bodyTable">
+<tr class="a">
+<td align="left"><tt>process-resources</tt></td>
+<td align="left"><tt>resources:resources</tt></td></tr>
+<tr class="b">
+<td align="left"><tt>compile</tt></td>
+<td align="left"><tt>compiler:compile</tt></td></tr>
+<tr class="a">
+<td align="left"><tt>process-test-resources</tt></td>
+<td align="left"><tt>resources:testResources</tt></td></tr>
+<tr class="b">
+<td align="left"><tt>test-compile</tt></td>
+<td align="left"><tt>compiler:testCompile</tt></td></tr>
+<tr class="a">
+<td align="left"><tt>test</tt></td>
+<td align="left"><tt>surefire:test</tt></td></tr>
+<tr class="b">
+<td align="left"><tt>package</tt></td>
+<td align="left"><tt>ejb:ejb</tt> <i>or</i> <tt>ejb3:ejb3</tt> <i>or</i> <tt>jar:jar</tt> <i>or</i> <tt>par:par</tt> <i>or</i> <tt>rar:rar</tt> <i>or</i> <tt>war:war</tt></td></tr>
+<tr class="a">
+<td align="left"><tt>install</tt></td>
+<td align="left"><tt>install:install</tt></td></tr>
+<tr class="b">
+<td align="left"><tt>deploy</tt></td>
+<td align="left"><tt>deploy:deploy</tt></td></tr></table></div>
+<div class="section">
+<h4>Default Lifecycle Bindings - Packaging <tt>ear</tt><a name="Default_Lifecycle_Bindings_-_Packaging_ear"></a></h4>
+<table border="1" class="bodyTable">
+<tr class="a">
+<td align="left"><tt>generate-resources</tt></td>
+<td align="left"><tt>ear:generateApplicationXml</tt></td></tr>
+<tr class="b">
+<td align="left"><tt>process-resources</tt></td>
+<td align="left"><tt>resources:resources</tt></td></tr>
+<tr class="a">
+<td align="left"><tt>package</tt></td>
+<td align="left"><tt>ear:ear</tt></td></tr>
+<tr class="b">
+<td align="left"><tt>install</tt></td>
+<td align="left"><tt>install:install</tt></td></tr>
+<tr class="a">
+<td align="left"><tt>deploy</tt></td>
+<td align="left"><tt>deploy:deploy</tt></td></tr></table></div>
+<div class="section">
+<h4>Default Lifecycle Bindings - Packaging <tt>maven-plugin</tt><a name="Default_Lifecycle_Bindings_-_Packaging_maven-plugin"></a></h4>
+<table border="1" class="bodyTable">
+<tr class="a">
+<td align="left"><tt>generate-resources</tt></td>
+<td align="left"><tt>plugin:descriptor</tt></td></tr>
+<tr class="b">
+<td align="left"><tt>process-resources</tt></td>
+<td align="left"><tt>resources:resources</tt></td></tr>
+<tr class="a">
+<td align="left"><tt>compile</tt></td>
+<td align="left"><tt>compiler:compile</tt></td></tr>
+<tr class="b">
+<td align="left"><tt>process-test-resources</tt></td>
+<td align="left"><tt>resources:testResources</tt></td></tr>
+<tr class="a">
+<td align="left"><tt>test-compile</tt></td>
+<td align="left"><tt>compiler:testCompile</tt></td></tr>
+<tr class="b">
+<td align="left"><tt>test</tt></td>
+<td align="left"><tt>surefire:test</tt></td></tr>
+<tr class="a">
+<td align="left"><tt>package</tt></td>
+<td align="left"><tt>jar:jar</tt> <i>and</i> <tt>plugin:addPluginArtifactMetadata</tt></td></tr>
+<tr class="b">
+<td align="left"><tt>install</tt></td>
+<td align="left"><tt>install:install</tt> <i>and</i> <tt>plugin:updateRegistry</tt></td></tr>
+<tr class="a">
+<td align="left"><tt>deploy</tt></td>
+<td align="left"><tt>deploy:deploy</tt></td></tr></table></div>
+<div class="section">
+<h4>Default Lifecycle Bindings - Packaging <tt>pom</tt><a name="Default_Lifecycle_Bindings_-_Packaging_pom"></a></h4>
+<table border="1" class="bodyTable">
+<tr class="a">
+<td align="left"><tt>package</tt></td>
+<td align="left"><tt>site:attach-descriptor</tt></td></tr>
+<tr class="b">
+<td align="left"><tt>install</tt></td>
+<td align="left"><tt>install:install</tt></td></tr>
+<tr class="a">
+<td align="left"><tt>deploy</tt></td>
+<td align="left"><tt>deploy:deploy</tt></td></tr></table></div>
+<div class="section">
+<h4>Site Lifecycle Bindings<a name="Site_Lifecycle_Bindings"></a></h4>
+<table border="1" class="bodyTable">
+<tr class="a">
+<td align="left"><tt>site</tt></td>
+<td align="left"><tt>site:site</tt></td></tr>
+<tr class="b">
+<td align="left"><tt>site-deploy</tt></td>
+<td align="left"><tt>site:deploy</tt></td></tr></table></div>
+<div class="section">
+<h4>References<a name="References"></a></h4>
+<p>The full Maven lifecycle is defined by the file <tt>components.xml</tt> in the module <tt>maven-core</tt> and viewable from SVN in the branches for <a class="externalLink" href="http://svn.apache.org/repos/asf/maven/maven-2/tags/maven-2.2.0/maven-core/src/main/resources/META-INF/plexus/components.xml">Maven 2.2.0</a> and <a class="externalLink" href="http://svn.apache.org/repos/asf/maven/maven-3/trunk/maven-core/src/main/resources/META-INF/plexus/components.xml">Maven 3.0.x</a>.</p>
+<p><i><a href="./introduction-to-the-lifecycle.html">[top]</a>.</i></p></div></div></div>
</div>
</div>
<div class="clear">
Modified: websites/staging/maven/trunk/content/guides/introduction/introduction-to-the-pom.html
==============================================================================
--- websites/staging/maven/trunk/content/guides/introduction/introduction-to-the-pom.html (original)
+++ websites/staging/maven/trunk/content/guides/introduction/introduction-to-the-pom.html Sat Apr 27 07:29:22 2013
@@ -1,6 +1,6 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!--
- | Generated by Apache Maven Doxia at Apr 23, 2013
+ | Generated by Apache Maven Doxia at Apr 27, 2013
| Rendered using Apache Maven Stylus Skin 1.5
-->
<html xmlns="http://www.w3.org/1999/xhtml">
@@ -16,7 +16,7 @@
Franz Allan Valencia See
Brett Porter" />
<meta name="Date-Creation-yyyymmdd" content="20090204" />
- <meta name="Date-Revision-yyyymmdd" content="20130423" />
+ <meta name="Date-Revision-yyyymmdd" content="20130427" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"></script>
@@ -46,7 +46,7 @@ Brett Porter" />
Introduction to the POM
</div>
<div class="xright">
- Last Published: 2013-04-23
+ Last Published: 2013-04-27
</div>
<div class="clear">
<hr/>
@@ -234,7 +234,37 @@ Brett Porter" />
</div>
<div id="bodyColumn">
<div id="contentBox">
- <div class="section"><h2>Introduction to the POM<a name="Introduction_to_the_POM"></a></h2><ul><li><a href="./introduction-to-the-pom.html#What_is_a_POM">What is a POM</a>?</li><li><a href="./introduction-to-the-pom.html#Super_POM">Super POM</a></li><li><a href="./introduction-to-the-pom.html#Minimal_POM">Minimal POM</a></li><li><a href="./introduction-to-the-pom.html#Project_Inheritance">Project Inheritance</a><ul><li><a href="./introduction-to-the-pom.html#Example_1">Example 1</a></li><li><a href="./introduction-to-the-pom.html#Example_2">Example 2</a></li></ul></li><li><a href="./introduction-to-the-pom.html#Project_Aggregation">Project Aggregation</a><ul><li><a href="./introduction-to-the-pom.html#Example_3">Example 3</a></li><li><a href="./introduction-to-the-pom.html#Example_4">Example 4</a></li></ul></li><li><a href="./introduction-to-the-pom.html#Project_Inheritance_vs_Project_Aggregation">Project Inheritance vs Project Aggregation</a><ul><li><a href="./intro
duction-to-the-pom.html#Example_5">Example 5</a></li></ul></li><li><a href="./introduction-to-the-pom.html#Project_Interpolation">Project Interpolation and Expressions</a><ul><li><a href="./introduction-to-the-pom.html#Available_Variables">Available Variables</a></li></ul></li></ul><div class="section"><h3><a name="What_is_a_POM">What is a POM</a>?</h3><p>A Project Object Model or POM is the fundamental unit of work in Maven. It is an XML file that contains information about the project and configuration details used by Maven to build the project. It contains default values for most projects. Examples for this is the build directory, which is <tt>target</tt>; the source directory, which is <tt>src/main/java</tt>; the test source directory, which is <tt>src/main/test</tt>; and so on.</p><p>The POM was renamed from <tt>project.xml</tt> in Maven 1 to <tt>pom.xml</tt> in Maven 2. Instead of having a <tt>maven.xml</tt> file that contains the goals that can be executed, the goals
or plugins are now configured in the <tt>pom.xml</tt>. When executing a task or goal, Maven looks for the POM in the current directory. It reads the POM, gets the needed configuration information, then executes the goal.</p><p>Some of the configuration that can be specified in the POM are the project dependencies, the plugins or goals that can be executed, the build profiles, and so on. Other information such as the project version, description, developers, mailing lists and such can also be specified.</p><p><a href="./introduction-to-the-pom.html">[top]</a></p></div><div class="section"><h3><a name="Super_POM">Super POM</a></h3><p>The Super POM is Maven's default POM. All POMs extend the Super POM unless explicitly set, meaning the configuration specified in the Super POM is inherited by the POMs you created for your projects. The snippet below is the Super POM for Maven 2.0.x.</p><div class="source"><pre><project>
+ <div class="section">
+<h2>Introduction to the POM<a name="Introduction_to_the_POM"></a></h2>
+<ul>
+<li><a href="./introduction-to-the-pom.html#What_is_a_POM">What is a POM</a>?</li>
+<li><a href="./introduction-to-the-pom.html#Super_POM">Super POM</a></li>
+<li><a href="./introduction-to-the-pom.html#Minimal_POM">Minimal POM</a></li>
+<li><a href="./introduction-to-the-pom.html#Project_Inheritance">Project Inheritance</a>
+<ul>
+<li><a href="./introduction-to-the-pom.html#Example_1">Example 1</a></li>
+<li><a href="./introduction-to-the-pom.html#Example_2">Example 2</a></li></ul></li>
+<li><a href="./introduction-to-the-pom.html#Project_Aggregation">Project Aggregation</a>
+<ul>
+<li><a href="./introduction-to-the-pom.html#Example_3">Example 3</a></li>
+<li><a href="./introduction-to-the-pom.html#Example_4">Example 4</a></li></ul></li>
+<li><a href="./introduction-to-the-pom.html#Project_Inheritance_vs_Project_Aggregation">Project Inheritance vs Project Aggregation</a>
+<ul>
+<li><a href="./introduction-to-the-pom.html#Example_5">Example 5</a></li></ul></li>
+<li><a href="./introduction-to-the-pom.html#Project_Interpolation">Project Interpolation and Expressions</a>
+<ul>
+<li><a href="./introduction-to-the-pom.html#Available_Variables">Available Variables</a></li></ul></li></ul>
+<div class="section">
+<h3><a name="What_is_a_POM">What is a POM</a>?</h3>
+<p>A Project Object Model or POM is the fundamental unit of work in Maven. It is an XML file that contains information about the project and configuration details used by Maven to build the project. It contains default values for most projects. Examples for this is the build directory, which is <tt>target</tt>; the source directory, which is <tt>src/main/java</tt>; the test source directory, which is <tt>src/main/test</tt>; and so on.</p>
+<p>The POM was renamed from <tt>project.xml</tt> in Maven 1 to <tt>pom.xml</tt> in Maven 2. Instead of having a <tt>maven.xml</tt> file that contains the goals that can be executed, the goals or plugins are now configured in the <tt>pom.xml</tt>. When executing a task or goal, Maven looks for the POM in the current directory. It reads the POM, gets the needed configuration information, then executes the goal.</p>
+<p>Some of the configuration that can be specified in the POM are the project dependencies, the plugins or goals that can be executed, the build profiles, and so on. Other information such as the project version, description, developers, mailing lists and such can also be specified.</p>
+<p><a href="./introduction-to-the-pom.html">[top]</a></p></div>
+<div class="section">
+<h3><a name="Super_POM">Super POM</a></h3>
+<p>The Super POM is Maven's default POM. All POMs extend the Super POM unless explicitly set, meaning the configuration specified in the Super POM is inherited by the POMs you created for your projects. The snippet below is the Super POM for Maven 2.0.x.</p>
+<div class="source">
+<pre><project>
<modelVersion>4.0.0</modelVersion>
<name>Maven Default Project</name>
@@ -344,7 +374,10 @@ Brett Porter" />
</profiles>
</project>
-</pre></div><p>The snippet below is the Super POM for Maven 2.1.x.</p><div class="source"><pre><project>
+</pre></div>
+<p>The snippet below is the Super POM for Maven 2.1.x.</p>
+<div class="source">
+<pre><project>
<modelVersion>4.0.0</modelVersion>
<name>Maven Default Project</name>
@@ -532,20 +565,65 @@ Brett Porter" />
</profiles>
</project>
-</pre></div><p><a href="./introduction-to-the-pom.html">[top]</a></p></div><div class="section"><h3><a name="Minimal_POM">Minimal POM</a></h3><p>The minimum requirement for a POM are the following:</p><ul><li>project root</li><li>modelVersion - should be set to 4.0.0</li><li>groupId - the id of the project's group.</li><li>artifactId - the id of the artifact (project)</li><li>version - the version of the artifact under the specified group</li></ul><p>Here's an example:</p><div class="source"><pre><project>
+</pre></div>
+<p><a href="./introduction-to-the-pom.html">[top]</a></p></div>
+<div class="section">
+<h3><a name="Minimal_POM">Minimal POM</a></h3>
+<p>The minimum requirement for a POM are the following:</p>
+<ul>
+<li>project root</li>
+<li>modelVersion - should be set to 4.0.0</li>
+<li>groupId - the id of the project's group.</li>
+<li>artifactId - the id of the artifact (project)</li>
+<li>version - the version of the artifact under the specified group</li></ul>
+<p>Here's an example:</p>
+<div class="source">
+<pre><project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<version>1</version>
-</project></pre></div><p>A POM requires that its groupId, artifactId, and version be configured. These three values form the project's fully qualified artifact name. This is in the form of <groupId>:<artifactId>:<version>. As for the example above, its fully qualified artifact name is "com.mycompany.app:my-app:1".</p><p>Also, as mentioned in the <a href="#What_is_a_POM">first section</a>, if the configuration details are not specified, Maven will use their defaults. One of these default values is the packaging type. Every Maven project has a packaging type. If it is not specified in the POM, then the default value "jar" would be used.</p><p>Furthermore, as you can see that in the minimal POM, the <i>repositories</i> were not specified. If you build your project using the minimal POM, it would inherit the <i>repositories</i> configuration in the Super POM. Therefore when Maven sees the dependencies in the minimal POM, it would know
that these dependencies will be downloaded from <tt>http://repo.maven.apache.org/maven2</tt> which was specified in the Super POM.</p><p><a href="./introduction-to-the-pom.html">[top]</a></p></div><div class="section"><h3><a name="Project_Inheritance">Project Inheritance</a></h3><p>Elements in the POM that are merged are the following:</p><ul><li>dependencies</li><li>developers and contributors</li><li>plugin lists (including reports)</li><li>plugin executions with matching ids</li><li>plugin configuration</li><li>resources</li></ul><p>The Super POM is one example of project inheritance, however you can also introduce your own parent POMs by specifying the parent element in the POM, as demonstrated in the following examples.</p><div class="section"><h4><a name="Example_1">Example 1</a></h4><div class="section"><h5>The Scenario<a name="The_Scenario"></a></h5><p>As an example, let us reuse our previous artifact, com.mycompany.app:my-app:1. And let us introduce another artifact
, com.mycompany.app:my-module:1.</p><div class="source"><pre><project>
+</project></pre></div>
+<p>A POM requires that its groupId, artifactId, and version be configured. These three values form the project's fully qualified artifact name. This is in the form of <groupId>:<artifactId>:<version>. As for the example above, its fully qualified artifact name is "com.mycompany.app:my-app:1".</p>
+<p>Also, as mentioned in the <a href="#What_is_a_POM">first section</a>, if the configuration details are not specified, Maven will use their defaults. One of these default values is the packaging type. Every Maven project has a packaging type. If it is not specified in the POM, then the default value "jar" would be used.</p>
+<p>Furthermore, as you can see that in the minimal POM, the <i>repositories</i> were not specified. If you build your project using the minimal POM, it would inherit the <i>repositories</i> configuration in the Super POM. Therefore when Maven sees the dependencies in the minimal POM, it would know that these dependencies will be downloaded from <tt>http://repo.maven.apache.org/maven2</tt> which was specified in the Super POM.</p>
+<p><a href="./introduction-to-the-pom.html">[top]</a></p></div>
+<div class="section">
+<h3><a name="Project_Inheritance">Project Inheritance</a></h3>
+<p>Elements in the POM that are merged are the following:</p>
+<ul>
+<li>dependencies</li>
+<li>developers and contributors</li>
+<li>plugin lists (including reports)</li>
+<li>plugin executions with matching ids</li>
+<li>plugin configuration</li>
+<li>resources</li></ul>
+<p>The Super POM is one example of project inheritance, however you can also introduce your own parent POMs by specifying the parent element in the POM, as demonstrated in the following examples.</p>
+<div class="section">
+<h4><a name="Example_1">Example 1</a></h4>
+<div class="section">
+<h5>The Scenario<a name="The_Scenario"></a></h5>
+<p>As an example, let us reuse our previous artifact, com.mycompany.app:my-app:1. And let us introduce another artifact, com.mycompany.app:my-module:1.</p>
+<div class="source">
+<pre><project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-module</artifactId>
<version>1</version>
-</project></pre></div><p>And let us specify their directory structure as the following:</p><div class="source"><pre>.
+</project></pre></div>
+<p>And let us specify their directory structure as the following:</p>
+<div class="source">
+<pre>.
|-- my-module
| `-- pom.xml
- `-- pom.xml</pre></div><p><b>Note:</b> <tt>my-module/pom.xml</tt> is the POM of com.mycompany.app:my-module:1 while <tt>pom.xml</tt> is the POM of com.mycompany.app:my-app:1</p></div><div class="section"><h5>The Solution<a name="The_Solution"></a></h5><p>Now, if we were to turn com.mycompany.app:my-app:1 into a parent artifact of com.mycompany.app:my-module:1,we will have to modify com.mycompany.app:my-module:1's POM to the following configuration:</p><p><b>com.mycompany.app:my-module:1's POM</b></p><div class="source"><pre><project>
+ `-- pom.xml</pre></div>
+<p><b>Note:</b> <tt>my-module/pom.xml</tt> is the POM of com.mycompany.app:my-module:1 while <tt>pom.xml</tt> is the POM of com.mycompany.app:my-app:1</p></div>
+<div class="section">
+<h5>The Solution<a name="The_Solution"></a></h5>
+<p>Now, if we were to turn com.mycompany.app:my-app:1 into a parent artifact of com.mycompany.app:my-module:1,we will have to modify com.mycompany.app:my-module:1's POM to the following configuration:</p>
+<p><b>com.mycompany.app:my-module:1's POM</b></p>
+<div class="source">
+<pre><project>
<parent>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
@@ -555,7 +633,11 @@ Brett Porter" />
<groupId>com.mycompany.app</groupId>
<artifactId>my-module</artifactId>
<version>1</version>
-</project></pre></div><p>Notice that we now have an added section, the parent section. This section allows us to specify which artifact is the parent of our POM. And we do so by specifying the fully qualified artifact name of the parent POM. With this setup, our module can now inherit some of the properties of our parent POM.</p><p>Alternatively, if we want the groupId and / or the version of your modules to be the same as their parents, you can remove the groupId and / or the version identity of your module in its POM.</p><div class="source"><pre><project>
+</project></pre></div>
+<p>Notice that we now have an added section, the parent section. This section allows us to specify which artifact is the parent of our POM. And we do so by specifying the fully qualified artifact name of the parent POM. With this setup, our module can now inherit some of the properties of our parent POM.</p>
+<p>Alternatively, if we want the groupId and / or the version of your modules to be the same as their parents, you can remove the groupId and / or the version identity of your module in its POM.</p>
+<div class="source">
+<pre><project>
<parent>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
@@ -563,11 +645,26 @@ Brett Porter" />
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>my-module</artifactId>
-</project></pre></div><p>This allows the module to inherit the groupId and / or the version of its parent POM.</p><p><a href="./introduction-to-the-pom.html">[top]</a></p></div></div><div class="section"><h4><a name="Example_2">Example 2</a></h4><div class="section"><h5>The Scenario<a name="The_Scenario"></a></h5><p>However, that would work if the parent project was already installed in our local repository or was in that specific directory structure (parent <tt>pom.xml</tt> is one directory higher than that of the module's <tt>pom.xml</tt>).</p><p>But what if the parent is not yet installed and if the directory structure is</p><div class="source"><pre>.
+</project></pre></div>
+<p>This allows the module to inherit the groupId and / or the version of its parent POM.</p>
+<p><a href="./introduction-to-the-pom.html">[top]</a></p></div></div>
+<div class="section">
+<h4><a name="Example_2">Example 2</a></h4>
+<div class="section">
+<h5>The Scenario<a name="The_Scenario"></a></h5>
+<p>However, that would work if the parent project was already installed in our local repository or was in that specific directory structure (parent <tt>pom.xml</tt> is one directory higher than that of the module's <tt>pom.xml</tt>).</p>
+<p>But what if the parent is not yet installed and if the directory structure is</p>
+<div class="source">
+<pre>.
|-- my-module
| `-- pom.xml
`-- parent
- `-- pom.xml</pre></div></div><div class="section"><h5>The Solution<a name="The_Solution"></a></h5><p>To address this directory structure (or any other directory structure), we would have to add the <tt><relativePath></tt> element to our parent section.</p><div class="source"><pre><project>
+ `-- pom.xml</pre></div></div>
+<div class="section">
+<h5>The Solution<a name="The_Solution"></a></h5>
+<p>To address this directory structure (or any other directory structure), we would have to add the <tt><relativePath></tt> element to our parent section.</p>
+<div class="source">
+<pre><project>
<parent>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
@@ -576,20 +673,47 @@ Brett Porter" />
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>my-module</artifactId>
-</project></pre></div><p>As the name suggests, it's the relative path from the module's <tt>pom.xml</tt> to the parent's <tt>pom.xml</tt>.</p></div></div></div><div class="section"><h3><a name="Project_Aggregation">Project Aggregation</a></h3><p>Project Aggregation is similar to <a href="#Project_Inheritance">Project Inheritance</a>. But instead of specifying the parent POM from the module, it specifies the modules from the parent POM. By doing so, the parent project now knows its modules, and if a Maven command is invoked against the parent project, that Maven command will then be executed to the parent's modules as well. To do Project Aggregation, you must do the following:</p><ul><li>Change the parent POMs packaging to the value "pom" .</li><li>Specify in the parent POM the directories of its modules (children POMs)</li></ul><p><a href="./introduction-to-the-pom.html">[top]</a></p><div class="section"><h4><a name="Example_3">Example 3</a></h4><div class="s
ection"><h5>The Scenario<a name="The_Scenario"></a></h5><p>Given the previous original artifact POMs, and directory structure,</p><p><b>com.mycompany.app:my-app:1's POM</b></p><div class="source"><pre><project>
+</project></pre></div>
+<p>As the name suggests, it's the relative path from the module's <tt>pom.xml</tt> to the parent's <tt>pom.xml</tt>.</p></div></div></div>
+<div class="section">
+<h3><a name="Project_Aggregation">Project Aggregation</a></h3>
+<p>Project Aggregation is similar to <a href="#Project_Inheritance">Project Inheritance</a>. But instead of specifying the parent POM from the module, it specifies the modules from the parent POM. By doing so, the parent project now knows its modules, and if a Maven command is invoked against the parent project, that Maven command will then be executed to the parent's modules as well. To do Project Aggregation, you must do the following:</p>
+<ul>
+<li>Change the parent POMs packaging to the value "pom" .</li>
+<li>Specify in the parent POM the directories of its modules (children POMs)</li></ul>
+<p><a href="./introduction-to-the-pom.html">[top]</a></p>
+<div class="section">
+<h4><a name="Example_3">Example 3</a></h4>
+<div class="section">
+<h5>The Scenario<a name="The_Scenario"></a></h5>
+<p>Given the previous original artifact POMs, and directory structure,</p>
+<p><b>com.mycompany.app:my-app:1's POM</b></p>
+<div class="source">
+<pre><project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<version>1</version>
-</project></pre></div><p><b>com.mycompany.app:my-module:1's POM</b></p><div class="source"><pre><project>
+</project></pre></div>
+<p><b>com.mycompany.app:my-module:1's POM</b></p>
+<div class="source">
+<pre><project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-module</artifactId>
<version>1</version>
-</project></pre></div><p><b>directory structure</b></p><div class="source"><pre>.
+</project></pre></div>
+<p><b>directory structure</b></p>
+<div class="source">
+<pre>.
|-- my-module
| `-- pom.xml
- `-- pom.xml</pre></div></div><div class="section"><h5>The Solution<a name="The_Solution"></a></h5><p>If we are to aggregate my-module into my-app, we would only have to modify my-app.</p><div class="source"><pre><project>
+ `-- pom.xml</pre></div></div>
+<div class="section">
+<h5>The Solution<a name="The_Solution"></a></h5>
+<p>If we are to aggregate my-module into my-app, we would only have to modify my-app.</p>
+<div class="source">
+<pre><project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
@@ -599,11 +723,27 @@ Brett Porter" />
<modules>
<module>my-module</module>
</modules>
-</project></pre></div><p>In the revised com.mycompany.app:my-app:1, the packaging section and the modules sections were added. For the packaging, its value was set to "pom", and for the modules section, we have the element <tt><module>my-module</module></tt>. The value of <tt><module></tt> is the relative path from the com.mycompany.app:my-app:1 to com.mycompany.app:my-module:1's POM (<i>by practice, we use the module's artifactId as the module directory's name</i>).</p><p>Now, whenever a Maven command processes com.mycompany.app:my-app:1, that same Maven command would be ran against com.mycompany.app:my-module:1 as well. Furthermore, some commands (goals specifically) handle project aggregation differently.</p><p><a href="./introduction-to-the-pom.html">[top]</a></p></div></div><div class="section"><h4><a name="Example_4">Example 4</a></h4><div class="section"><h5>The Scenario<a name="The_Scenario"></a></h5><p>But what if we change the dire
ctory structure to the following:</p><div class="source"><pre>.
+</project></pre></div>
+<p>In the revised com.mycompany.app:my-app:1, the packaging section and the modules sections were added. For the packaging, its value was set to "pom", and for the modules section, we have the element <tt><module>my-module</module></tt>. The value of <tt><module></tt> is the relative path from the com.mycompany.app:my-app:1 to com.mycompany.app:my-module:1's POM (<i>by practice, we use the module's artifactId as the module directory's name</i>).</p>
+<p>Now, whenever a Maven command processes com.mycompany.app:my-app:1, that same Maven command would be ran against com.mycompany.app:my-module:1 as well. Furthermore, some commands (goals specifically) handle project aggregation differently.</p>
+<p><a href="./introduction-to-the-pom.html">[top]</a></p></div></div>
+<div class="section">
+<h4><a name="Example_4">Example 4</a></h4>
+<div class="section">
+<h5>The Scenario<a name="The_Scenario"></a></h5>
+<p>But what if we change the directory structure to the following:</p>
+<div class="source">
+<pre>.
|-- my-module
| `-- pom.xml
`-- parent
- `-- pom.xml</pre></div><p>How would the parent pom specify its modules?</p></div><div class="section"><h5>The Solution<a name="The_Solution"></a></h5><p>The answer? - the same way as Example 3, by specifying the path to the module.</p><div class="source"><pre><project>
+ `-- pom.xml</pre></div>
+<p>How would the parent pom specify its modules?</p></div>
+<div class="section">
+<h5>The Solution<a name="The_Solution"></a></h5>
+<p>The answer? - the same way as Example 3, by specifying the path to the module.</p>
+<div class="source">
+<pre><project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
@@ -613,21 +753,51 @@ Brett Porter" />
<modules>
<module>../my-module</module>
</modules>
-</project></pre></div></div></div></div><div class="section"><h3><a name="Project_Inheritance_vs_Project_Aggregation">Project Inheritance vs Project Aggregation</a></h3><p>If you have several Maven projects, and they all have similar configurations, you can refactor your projects by pulling out those similar configurations and making a parent project. Thus, all you have to do is to let your Maven projects inherit that parent project, and those configurations would then be applied to all of them.</p><p>And if you have a group of projects that are built or processed together, you can create a parent project and have that parent project declare those projects as its modules. By doing so, you'd only have to build the parent and the rest will follow.</p><p>But of course, you can have both Project Inheritance and Project Aggregation. Meaning, you can have your modules specify a parent project, and at the same time, have that parent project specify those Maven projects as its
modules. You'd just have to apply all three rules:</p><ul><li>Specify in every child POM who their parent POM is.</li><li>Change the parent POMs packaging to the value "pom" .</li><li>Specify in the parent POM the directories of its modules (children POMs)</li></ul><p><a href="./introduction-to-the-pom.html">[top]</a></p><div class="section"><h4><a name="Example_5">Example 5</a></h4><div class="section"><h5>The Scenario<a name="The_Scenario"></a></h5><p>Given the previous original artifact POMs again,</p><p><b>com.mycompany.app:my-app:1's POM</b></p><div class="source"><pre><project>
+</project></pre></div></div></div></div>
+<div class="section">
+<h3><a name="Project_Inheritance_vs_Project_Aggregation">Project Inheritance vs Project Aggregation</a></h3>
+<p>If you have several Maven projects, and they all have similar configurations, you can refactor your projects by pulling out those similar configurations and making a parent project. Thus, all you have to do is to let your Maven projects inherit that parent project, and those configurations would then be applied to all of them.</p>
+<p>And if you have a group of projects that are built or processed together, you can create a parent project and have that parent project declare those projects as its modules. By doing so, you'd only have to build the parent and the rest will follow.</p>
+<p>But of course, you can have both Project Inheritance and Project Aggregation. Meaning, you can have your modules specify a parent project, and at the same time, have that parent project specify those Maven projects as its modules. You'd just have to apply all three rules:</p>
+<ul>
+<li>Specify in every child POM who their parent POM is.</li>
+<li>Change the parent POMs packaging to the value "pom" .</li>
+<li>Specify in the parent POM the directories of its modules (children POMs)</li></ul>
+<p><a href="./introduction-to-the-pom.html">[top]</a></p>
+<div class="section">
+<h4><a name="Example_5">Example 5</a></h4>
+<div class="section">
+<h5>The Scenario<a name="The_Scenario"></a></h5>
+<p>Given the previous original artifact POMs again,</p>
+<p><b>com.mycompany.app:my-app:1's POM</b></p>
+<div class="source">
+<pre><project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<version>1</version>
-</project></pre></div><p><b>com.mycompany.app:my-module:1's POM</b></p><div class="source"><pre><project>
+</project></pre></div>
+<p><b>com.mycompany.app:my-module:1's POM</b></p>
+<div class="source">
+<pre><project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-module</artifactId>
<version>1</version>
-</project></pre></div><p>and this <b>directory structure</b></p><div class="source"><pre>.
+</project></pre></div>
+<p>and this <b>directory structure</b></p>
+<div class="source">
+<pre>.
|-- my-module
| `-- pom.xml
`-- parent
- `-- pom.xml</pre></div></div><div class="section"><h5>The Solution<a name="The_Solution"></a></h5><p>To do both project inheritance and aggregation, you only have to apply all three rules.</p><p><b>com.mycompany.app:my-app:1's POM</b></p><div class="source"><pre><project>
+ `-- pom.xml</pre></div></div>
+<div class="section">
+<h5>The Solution<a name="The_Solution"></a></h5>
+<p>To do both project inheritance and aggregation, you only have to apply all three rules.</p>
+<p><b>com.mycompany.app:my-app:1's POM</b></p>
+<div class="source">
+<pre><project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
@@ -637,7 +807,10 @@ Brett Porter" />
<modules>
<module>../my-module</module>
</modules>
-</project></pre></div><p><b>com.mycompany.app:my-module:1's POM</b></p><div class="source"><pre><project>
+</project></pre></div>
+<p><b>com.mycompany.app:my-module:1's POM</b></p>
+<div class="source">
+<pre><project>
<parent>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
@@ -646,13 +819,49 @@ Brett Porter" />
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>my-module</artifactId>
-</project></pre></div><p><b>NOTE:</b> Profile inheritance the same inheritance strategy as used for the POM itself.</p><p><a href="./introduction-to-the-pom.html">[top]</a></p></div></div></div><div class="section"><h3><a name="Project_Interpolation">Project Interpolation</a> and Variables<a name="Project_Interpolation_and_Variables"></a></h3><p>One of the practices that Maven encourages is <i>don't repeat yourself</i>. However, there are circumstances where you will need to use the same value in several different locations. To assist in ensuring the value is only specified once, Maven allows you to use both your own and pre-defined variables in the POM.</p><p>For example, to access the <tt>project.version</tt> variable, you would reference it like so:</p><div class="source"><pre> <version>${project.version}</version></pre></div><p>One factor to note is that these variables are processed <i>after</i> inheritance as outlined above. This means that if a pare
nt project uses a variable, then its definition in the child, not the parent, will be the one eventually used.</p><div class="section"><h4><a name="Available_Variables">Available Variables</a></h4><div class="section"><h5>Project Model Variables<a name="Project_Model_Variables"></a></h5><p>Any field of the model that is a single value element can be referenced as a variable. For example, <tt>${project.groupId}</tt>, <tt>${project.version}</tt>, <tt>${project.build.sourceDirectory}</tt> and so on. Refer to the POM reference to see a full list of properties.</p><p>These variables are all referenced by the prefix "<tt>project.</tt>". You may also see references with <tt>pom.</tt> as the prefix, or the prefix omitted entirely - these forms are now deprecated and should not be used.</p></div><div class="section"><h5>Special Variables<a name="Special_Variables"></a></h5><table border="1" class="bodyTable"><tr class="a"><td align="left"><tt>project.basedir</tt></td><td al
ign="left">The directory that the current project resides in.</td></tr><tr class="b"><td align="left"><tt>project.baseUri</tt></td><td align="left">The directory that the current project resides in, represented as an URI. <i>Since Maven 2.1.0</i></td></tr><tr class="a"><td align="left"><tt>maven.build.timestamp</tt></td><td align="left">The timestamp that denotes the start of the build. <i>Since Maven 2.1.0-M1</i></td></tr></table><p>The format of the build timestamp can be customized by declaring the property <tt>maven.build.timestamp.format</tt> as shown in the example below:</p><div class="source"><pre><project>
+</project></pre></div>
+<p><b>NOTE:</b> Profile inheritance the same inheritance strategy as used for the POM itself.</p>
+<p><a href="./introduction-to-the-pom.html">[top]</a></p></div></div></div>
+<div class="section">
+<h3><a name="Project_Interpolation">Project Interpolation</a> and Variables<a name="Project_Interpolation_and_Variables"></a></h3>
+<p>One of the practices that Maven encourages is <i>don't repeat yourself</i>. However, there are circumstances where you will need to use the same value in several different locations. To assist in ensuring the value is only specified once, Maven allows you to use both your own and pre-defined variables in the POM.</p>
+<p>For example, to access the <tt>project.version</tt> variable, you would reference it like so:</p>
+<div class="source">
+<pre> <version>${project.version}</version></pre></div>
+<p>One factor to note is that these variables are processed <i>after</i> inheritance as outlined above. This means that if a parent project uses a variable, then its definition in the child, not the parent, will be the one eventually used.</p>
+<div class="section">
+<h4><a name="Available_Variables">Available Variables</a></h4>
+<div class="section">
+<h5>Project Model Variables<a name="Project_Model_Variables"></a></h5>
+<p>Any field of the model that is a single value element can be referenced as a variable. For example, <tt>${project.groupId}</tt>, <tt>${project.version}</tt>, <tt>${project.build.sourceDirectory}</tt> and so on. Refer to the POM reference to see a full list of properties.</p>
+<p>These variables are all referenced by the prefix "<tt>project.</tt>". You may also see references with <tt>pom.</tt> as the prefix, or the prefix omitted entirely - these forms are now deprecated and should not be used.</p></div>
+<div class="section">
+<h5>Special Variables<a name="Special_Variables"></a></h5>
+<table border="1" class="bodyTable">
+<tr class="a">
+<td align="left"><tt>project.basedir</tt></td>
+<td align="left">The directory that the current project resides in.</td></tr>
+<tr class="b">
+<td align="left"><tt>project.baseUri</tt></td>
+<td align="left">The directory that the current project resides in, represented as an URI. <i>Since Maven 2.1.0</i></td></tr>
+<tr class="a">
+<td align="left"><tt>maven.build.timestamp</tt></td>
+<td align="left">The timestamp that denotes the start of the build. <i>Since Maven 2.1.0-M1</i></td></tr></table>
+<p>The format of the build timestamp can be customized by declaring the property <tt>maven.build.timestamp.format</tt> as shown in the example below:</p>
+<div class="source">
+<pre><project>
...
<properties>
<maven.build.timestamp.format>yyyyMMdd-HHmm</maven.build.timestamp.format>
</properties>
...
-</project></pre></div><p>The format pattern has to comply with the rules given in the API documentation for <a class="externalLink" href="http://java.sun.com/javase/6/docs/api/java/text/SimpleDateFormat.html">SimpleDateFormat</a>. If the property is not present, the format defaults to the value already given in the example.</p></div><div class="section"><h5>Properties<a name="Properties"></a></h5><p>You are also able to reference any properties defined in the project as a variable. Consider the following example:</p><div class="source"><pre><project>
+</project></pre></div>
+<p>The format pattern has to comply with the rules given in the API documentation for <a class="externalLink" href="http://java.sun.com/javase/6/docs/api/java/text/SimpleDateFormat.html">SimpleDateFormat</a>. If the property is not present, the format defaults to the value already given in the example.</p></div>
+<div class="section">
+<h5>Properties<a name="Properties"></a></h5>
+<p>You are also able to reference any properties defined in the project as a variable. Consider the following example:</p>
+<div class="source">
+<pre><project>
...
<properties>
<mavenVersion>2.1</mavenVersion>
@@ -670,7 +879,8 @@ Brett Porter" />
</dependency>
</dependencies>
...
-</project></pre></div><p><a href="./introduction-to-the-pom.html">[top]</a></p></div></div></div></div>
+</project></pre></div>
+<p><a href="./introduction-to-the-pom.html">[top]</a></p></div></div></div></div>
</div>
</div>
<div class="clear">