Author: vsiveton
Date: Wed Jan 9 17:18:23 2008
New Revision: 610629
URL: http://svn.apache.org/viewvc?rev=610629&view=rev
Log:
MNG-2655: Revise Introduction to the Build Lifecycle
o patch applied
Modified:
maven/site/trunk/src/site/apt/guides/introduction/introduction-to-the-lifecycle.apt
Modified:
maven/site/trunk/src/site/apt/guides/introduction/introduction-to-the-lifecycle.apt
URL:
http://svn.apache.org/viewvc/maven/site/trunk/src/site/apt/guides/introduction/introduction-to-the-lifecycle.apt?rev=610629&r1=610628&r2=610629&view=diff
==============================================================================
---
maven/site/trunk/src/site/apt/guides/introduction/introduction-to-the-lifecycle.apt
(original)
+++
maven/site/trunk/src/site/apt/guides/introduction/introduction-to-the-lifecycle.apt
Wed Jan 9 17:18:23 2008
@@ -6,17 +6,58 @@
16 June 2005
------
+ ~~ 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/guides/mini/guide-apt-format.html
+
Introduction to the Build Lifecycle
-* Build Lifecycle Basics
+* Table Of Contents
+
+ * {{{introduction-to-the-lifecycle.html#Build_Lifecycle_Basics}Build
Lifecycle Basics}}
+
+ *
{{{introduction-to-the-lifecycle.html#Setting_Up_Your_Project_To_Use_The_Build_Lifecycle}Setting
Up Your Project To Use The Build Lifecycle}}
+
+ * {{{introduction-to-the-lifecycle.html#Packaging}Packaging}}
+
+ * {{{introduction-to-the-lifecycle.html#Plugins}Plugins}}
+
+ * {{{introduction-to-the-lifecycle.html#Lifecycle_Reference}Lifecycle
Reference}}
+
+ []
+
+* {Build Lifecycle Basics}
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 is clearly defined.
+ and distributing a particular artifact (project) is clearly defined.
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 POM will ensure they get the results they desired.
- The most common lifecycle phases that would be executed on a project are
the following (a complete list of the lifecycle phases is given below):
+ 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.
+
+** {A Build Lifecycle is Made Up of Phases}
+
+ Each of these build lifecycles are defined by a different list of build
phases, wherein a build phase represents a
+ stage in the lifecycle.
+
+ For example, the default lifecycle has the following build phases (for a
complete list of the build phases, refer
+ to the {{{introduction-to-the-lifecycle#lifecycle_reference}Lifecycle
Reference}}):
* <<<validate>>> - validate the project is correct and all necessary
information is available
@@ -37,18 +78,31 @@
* <<<deploy>>> - done in an integration or release environment, copies the
final package to the remote repository
for sharing with other developers and projects.
- Note that for each of these steps, all previous steps are always executed,
so you only need to specify the last one
- you desire on the command line. For example:
+ These build phases (plus the other build phases not shown here) and 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, packages the binaries (i.e jar), run
+ integration tests against that package, verifies the packaging, install the
verifed package to the local repository,
+ then depoy the installed package in a specified environment.
+
+ To do all those, you only need to call the last build phase to be executed,
in this case, deploy.
-------
-mvn install
+mvn deploy
-------
- This command will compile, test, package, verify and install the package
into the local repository when run.
+ 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
+
+-------
+mvn integration-test
+-------
+
+ Will do every build phase before it (validate, compile, package), before
executing integration-test.
There are more commands that are part of the lifecycle, which will be
discussed in the following sections.
- It should also be noted that the same command can be used in a multi-module
scenario. For example;
+ 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;
------
mvn clean install
@@ -57,16 +111,49 @@
This command will traverse into all of the subprojects and run <<<clean>>>,
then <<<install>>> (including all of
the prior steps).
-* Setting up your Project to Use the Build Lifecycle
+ <{{{introduction-to-the-lifecycle.html}[top]}}.>
+
+** {A Build Phase is Made Up of Goals}
+
+ 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.
+
+ A goal represents a specific task (finer than a build phase) which
contributes to the building and managing of a
+ project. It may bound itself to zero or more build phases. And a goal not
bound to any build phase executes outside of
+ the build lifecycle. The order of execution depends on the order in which
the goal(s) and the build phase(s) are
+ invoked. For exmaple, the in command below. The <<<clean>>> and
<<<package>>> arguments are build phases. While the
+ <<<dependency:copy-dependencies>>> is a goal.
+
+------
+mvn clean dependency:copy-dependencies package
+------
+
+ If this were to be executed, the <<<clean>>> phase will first be executed
(meaning it will run all preceeding phases,
+ plus the <<<clean>>> phase itself), and then the
<<<dependency:copy-dependencies>>> goal, before finally executing the
+ <<<package>>> phase (and all its preceeding build phases).
+
+ Moreover, if a goal is bound to one or more build phases, that goal will be
called in all those phases.
+
+ 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
+ (<Note: as of maven-2.0.5, multiple goals bound to a phase are executed in
the same order as they are declared in the
+ POM>).
+
+* {Setting Up Your Project To Use The Build Lifecycle}
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?
-** Packaging
+ <{{{introduction-to-the-lifecycle.html}[top]}}.>
+
+** {Packaging}
- The first, and most common way, is to set the <<<packaging>>> for your
project. This defaults to <<<jar>>>, so whether
- you have specifically done it or not, this has already happened. Each
packaging contains a list of goals to bind to
- a particular phase. For example, a JAR will add the following bindings to the
lifecycle:
+ The first, and most common way, is to set the <<<packaging>>> for your
project. Some of the valid <<<packaging>>>
+ values are <<<jar>>>, <<<war>>>, <<<ear>>>, and <<<pom>>>. If no packaging
value have been specified, it will default
+ to <<<jar>>>.
+
+ Each packaging contains a list of goals to bind to a particular phase. For
example, a JAR will bind the following build
+ phases to the default lifecycle.
*------------------------------+---------------------------------------------------------------------------------------+
| <<<process-resources>>> | <<<resources:resources>>>
@@ -87,26 +174,36 @@
*------------------------------+---------------------------------------------------------------------------------------+
This is an almost standard set of bindings; however, some packages handle
them differently. For example, a project
- that is purely metadata (packaging <<<pom>>>) only binds the <<<install>>>
and <<<deploy>>> phases.
+ that is purely metadata (packaging value is <<<pom>>>) only binds the
<<<install>>> and <<<deploy>>> phases (for a
+ complete list of build-phase-to-goal binding of some of the
<<<packaging>>>s, refer to the
+ {{{introduction-to-the-lifecycle#lifecycle_reference}Lifecycle Reference}}).
Note that for some packaging types to be available, you may also need to
include a particular plugin in your
- <<<build>>> section (as described in the next section). One example of a
plugin that requires this is the Plexus plugin,
- which provides a <<<plexus-application>>> and <<<plexus-service>>> packaging.
+ <<<build>>> section of your POM (as described in the next section). One
example of a plugin that requires this is the
+ Plexus plugin, which provides a <<<plexus-application>>> and
<<<plexus-service>>> packaging.
+
+ <{{{introduction-to-the-lifecycle.html}[top]}}.>
-** Plugins
+** {Plugins}
- The second way to add goals to phases is to configure plugins in your
project. As you will see in the later sections,
- plugins contain information that indicate which lifecycle phase to bind each
goal to. Note that adding the plugin on its own is not
- enough information - you must also specify the goals you want run as part of
your build.
+ The second way to add goals to phases is to configure plugins in your
project. Plugins are artifacts that provides
+ goals to Maven. Furthermore, a plugin may have one or more goals wherein
each goal represents a capability of that
+ plugin. For example, the <<<maven-compiler-plugin>>> has two goals:
<<<compile>>> and <<<testCompile>>>. The former
+ compiles the source code of your main code, while the latter compiles the
source code of your test codes.
+
+ As you will see in the later sections, plugins contain information that
indicate which lifecycle phase to bind each
+ goal to. Note that adding the plugin on its own is not enough information -
you must also specify the goals you want
+ run as part of your build.
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
<<<executions>>> element to gain more
control over the order of particular goals.
- For example, the Modello plugin always binds <<<modello:java>>> to the
<<<generate-sources>>> phase. 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 <<<plugins>>> section of <<<build>>>:
+ For example, the Modello plugin always binds <<<modello:java>>> to the
<<<generate-sources>>> phase (Note: the
+ <<<modello:java>>> 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 <<<plugins>>> section of
+ <<<build>>>:
----
...
@@ -137,21 +234,18 @@
Now, in the case of <<<modello:java>>>, it only makes sense in the
<<<generate-sources>>> 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 <<<touch:timestamp>>> that echos the
current time to a file, and you want it to
- run in the <<<process-test-resources>>> phase to indicate when the tests
were started. This would be configured like
- so:
+ For example, let's say you have a goal <<<display:time>>> that echos the
current time to the commandline, and you want
+ it to run in the <<<process-test-resources>>> phase to indicate when the
tests were started. This would be configured
+ like so:
----
...
<plugin>
<groupId>com.mycompany.example</groupId>
- <artifactId>touch-maven-plugin</artifactId>
+ <artifactId>maven-touch-plugin</artifactId>
<executions>
<execution>
<phase>process-test-resources</phase>
- <configuration>
- <file>${project.output.directory}/timestamp.txt</file>
- </configuration>
<goals>
<goal>timestamp</goal>
</goals>
@@ -161,9 +255,24 @@
...
----
-* Build Lifecycle Phase Reference
+ <{{{introduction-to-the-lifecycle.html}[top]}}.>
- The following lists all build lifecycle phases, which are executed in the
order given up to the point of the one specified.
+* {Lifecycle Reference}
+
+ 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.
+
+ <<Clean Lifecycle>>
+
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<pre-clean>>> | executes processes needed prior to the
actual project cleaning
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<clean>>> | remove all files generated by the previous
build
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<post-clean>>> | executes processes needed to finalize the
project cleaning
+*-------------------------------+--------------------------------------------------------------------------------------+
+
+ <<Default Lifecycle>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<validate>>> | validate the project is correct and all
necessary information is available.
@@ -209,247 +318,105 @@
| <<<deploy>>> | done in an integration or release
environment, copies the final package to the remote repository for sharing with
other developers and projects.
*-------------------------------+--------------------------------------------------------------------------------------+
-* How the Build Lifecycle Affects Plugin Developers
-
- The build lifecycle ensures that plugin developers only need to make their
individual goal (a "mojo") perform a single
- task with a simple set of inputs and outputs, and then have that goal bound
to the appropriate stage of the build.
-
- Information is passed between goals only through the project object - for
example by adding new compile source roots,
- changing the location of the classes directory after processing, and so on.
-
- There are 3 ways that a plugin can interact with the build lifecycle: by
binding a mojo to a particular phase, by
- specifying an alternate packaging and appropriate lifecycle bindings, or by
forking a parallel lifecycle.
-
-** Binding a Mojo to a Phase
-
- If the mojo is participating in a part of the normal build, usually the
plugin developer will bind that mojo to a
- particular phase, using the following syntax in the mojo level declaration:
-
-----
[EMAIL PROTECTED] generate-sources
-----
+ <<Site Lifecycle>>
- <<Note:>> <Some plugin languages have different ways of specifying mojo
level declarations.
- Please refer to the specific plugin development documentation for more
information.>
-
- Once this is specified, it will automatically be registered when the goal is
listed in the project POM, as described
- previously.
-
-** Specifying a New Packaging
-
- If your plugin is intended to provide a unique artifact type, then you will
need to provide not only the goal to
- package it with, but also a mapping of how the default lifecycle should
behave.
-
- This is currently achieved by adding a Plexus descriptor to your plugin (or
modifying it if it already exists).
- This file is <<<META-INF/plexus/components.xml>>> in the plugin JAR. The
following is an example of configuring a
- set of phases for the Plexus plugin itself to register the
<<<plexus-application>>> type:
-
-----
-<component-set>
- <components>
- <component>
- <role>org.apache.maven.lifecycle.mapping.LifecycleMapping</role>
- <role-hint>plexus-application</role-hint>
-
<implementation>org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping</implementation>
- <configuration>
- <phases>
-
<process-resources>org.apache.maven.plugins:maven-resources-plugin:resources</process-resources>
-
<compile>org.apache.maven.plugins:maven-compiler-plugin:compile</compile>
-
<process-test-resources>org.apache.maven.plugins:maven-resources-plugin:testResources</process-test-resources>
-
<test-compile>org.apache.maven.plugins:maven-compiler-plugin:testCompile</test-compile>
- <test>org.apache.maven.plugins:maven-surefire-plugin:test</test>
- <package>org.codehaus.plexus:plexus-maven-plugin:app</package>
-
<install>org.apache.maven.plugins:maven-install-plugin:install</install>
- <deploy>org.apache.maven.plugins:maven-deploy-plugin:deploy</deploy>
- </phases>
- </configuration>
- </component>
- </components>
-</component-set>
-----
-
- In this example, the <<<role-hint>>> is used to specify the packaging, and
the <<<role>>> of
- <<<org.apache.maven.lifecycle.mapping.LifecycleMapping>>> indicates this is
a lifecycle mapping for that packaging.
- <<<implementation>>> is required, and while you can provide your own, the
default given above should suit the standard case.
-
- The phases to bind are listed in the configuration element, and each that is
given can have one goal associated with
- that phase for that particular packaging. Note that the goal must be "fully
qualified" in a <<<groupId:artifactId:goal>>>
- or <<<groupId:artifactId:version:goal>>> format, as the normal prefix can
resolve to a different plugin dependending on
- configuration.
-
- Once this is included in the JAR, the plugin needs to be added to the
project to make the packaging available from
- that project. In addition to listing the plugin, you must specify that it
provides extensions:
-
-----
-...
- <packaging>plexus-application</packaging>
-...
- <plugin>
- <groupId>org.codehaus.plexus</groupId>
- <artifactId>plexus-maven-plugin</artifactId>
- <extensions>true</extensions>
- </plugin>
-...
-----
-
- Setting the extensions flag is also necessary if you provide custom artifact
type handlers (closely related to
- providing a packaging).
-
- One final task that is required is for the packaging goal you have created
to tell Maven where to find what you built. This is
- done with code such as the following:
-
-----
-project.getArtifact().setFile( new File( "target/myFile-2.0.jar" ) );
-----
-
-** Creating a Custom Artifact Handler
-
- The default artifact handler maps the packaging, type, and file extension to
the same value. For example, if you create a
- packaging of <<<plexus-application>>>, then the file in the repository will
be <<<myartifactId-1.0.plexus-application>>>.
- The same applies if you request a particular <<<type>>> from a dependency.
-
- If you want to change that extension, or change how a dependency's
<<<type>>> field is mapped to the other fields, you must
- include a custom artifact handler in your plugin.
-
- Like giving a packaging, this is currently achieved by adding a Plexus
descriptor to your plugin (or modifying it if it
- already exists). This file is <<<META-INF/plexus/components.xml>>> in the
plugin JAR.
-
- A complete artifact handler for the <<<test-jar>>> type looks like this:
+*-------------------------------+--------------------------------------------------------------------------------------+
+| pre-site | executes processes needed prior to the
actual project site generation
+*-------------------------------+--------------------------------------------------------------------------------------+
+| site | generates the project's site documentation
+*-------------------------------+--------------------------------------------------------------------------------------+
+| post-site | executes processes needed to finalize the
site generation, and to prepare for site deployment
+*-------------------------------+--------------------------------------------------------------------------------------+
+| site-deploy | deploys the generated site documentation to
the specified web server
+*-------------------------------+--------------------------------------------------------------------------------------+
-----
-<component-set>
- <components>
- <component>
- <role>org.apache.maven.artifact.handler.ArtifactHandler</role>
- <role-hint>test-jar</role-hint>
-
<implementation>org.apache.maven.artifact.handler.DefaultArtifactHandler</implementation>
- <configuration>
- <classifier>tests</classifier>
- <extension>jar</extension>
- <type>test-jar</type>
- <packaging>jar</packaging>
- <language>java</language>
- <addedToClasspath>true</addedToClasspath>
- </configuration>
- </component>
- </components>
-</component-set>
-----
+ Furthermore, some phases have goals binded to it by default. And for the
default lifecycle, the bindings depends on
+ the <<<packaging>>> value. Here are some of the build-phase-to-goal bindings.
- The fields are configured as follows:
+ <<Clean Lifecycle Bindings>>
-*----------------------------+---------------+---------------------+---------------------------------+
-| <<Field>> | <<Required?>> | <<Default>> |
<<Description>>
-*----------------------------+---------------+---------------------+---------------------------------+
-| <<<role-hint>>> | Y | | The type
being defined.
-*----------------------------+---------------+---------------------+---------------------------------+
-| <<<type>>> | Y | | Must
match the <<<role-hint>>>.
-*----------------------------+---------------+---------------------+---------------------------------+
-| <<<extension>>> | N | The type | The
extension to give the artifact in the repository.
-*----------------------------+---------------+---------------------+---------------------------------+
-| <<<packaging>>> | N | The type | The
packaging of the artifact to look for.
-*----------------------------+---------------+---------------------+---------------------------------+
-| <<<classifier>>> | N | | The
classifier to append to the artifact name (after version and before extension)
when using this type.
-*----------------------------+---------------+---------------------+---------------------------------+
-| <<<language>>> | N | <<<java>>> | The
language the artifact is written in. No set values - free text.
-*----------------------------+---------------+---------------------+---------------------------------+
-| <<<addedToClasspath>>> | N | <<<true>>> | Whether
the artifact should be included in a classpath or library path when used.
-*----------------------------+---------------+---------------------+---------------------------------+
-| <<<includesDependencies>>> | N | <<<false>>> | If the
artifact already includes all of its dependencies, this setting ensures they
are not propogated transitively.
-*----------------------------+---------------+---------------------+---------------------------------+
-
- As above, the extensions flag will need to be provided whenever the plugin
is declared and the type is used.
-
-** Forking a Parallel Lifecycle
-
- While lots of mojos will participate in the standard lifecycle, there are
just as many that are used in other
- scenarios. These are mojos that are executed standalone from the command
line (such as <<<idea:idea>>>), or individual
- reports in the site building process.
-
- However, sometimes these goals require that a particular task has already
been performed - for instance, the IDEA
- plugin must ensure sources have been generated to properly construct its
module files. If the goal were participating
- in the lifecycle, it would easily do this by ensuring it occurred after the
phase it depended on having run. Since
- this isn't the case, it must have a way to first execute that task.
-
- Additionally, even goals participating in the build lifecycle might need to
perform a task with different parameters
- to what was already used, and does not want the output to affect the current
build (for example, running
- <<<clover:check>>> to run tests with modified sources and fail if a certain
coverage ratio is not achieved).
-
- For these reasons, mojos are capable of forking a new lifecycle. The
lifecycle will be a normal build lifecycle,
- a clone of the one currently being used (including any additional bindings
from the POM), executed up until the point
- specified by the mojo.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<clean>>> | <<<clean:clean>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
- For example, the <<<idea:idea>>> mojo specifies the following in the mojo
level declarations to call the source
- generation:
+ <<Default Lifecycle - EJB / EJB3 / JAR / PAR / RAR / WAR Packaging>>
-----
[EMAIL PROTECTED] phase="generate-sources"
-----
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<process-resources>>> | <<<resources:resources>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<compile>>> | <<<compiler:compile>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<process-test-resources>>> | <<<resources:testResource>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<test-compile>>> | <<<compiler:testCompile>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<test>>> | <<<surefire:test>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<package>>> | <<<ejb:ejb>>> <or> <<<ejb3:ejb3>>> <or>
<<<jar:jar>>> <or> <<<par:par>>> <or> <<<rar:rar>>> <or> <<<war:war>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<install>>> | <<<install:install>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<deploy>>> | <<<deploy:deploy>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
- But what happens if <<<generate-sources>>> has already been run in this
build? In the current version of Maven, there
- is no way to tell if the previous execution used the same input and outputs
as the current mojo requires, so the task
- (and any preceding ones if from the lifecycle) must be run again.
-
- For this reason, it is important that if your plugin does any intensive
work, you should first check whether it is
- necessary to perform the tasks again, perhaps by using timestamp checking or
a similar technique. As an example,
- the compiler plugin will only recompile changed source files so can very
efficiently be run multiple times in a build
- if necessary.
-
- When the lifecycle is forked, the project object being used is also cloned.
In this way, modifications made to the
- project as part of the execution, such as the addition of a new source root,
will not affect the original build.
- When the lifecycle finishes executing and control is passed to the original
mojo, it can access that project using
- the expression <<<${executedProject}>>>. For example:
+ <<Default Lifecycle - EAR Packaging>>
-----
-/**
- * @parameter expression="${executedProject}"
- */
-private MavenProject executedProject;
-----
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<generate-resources>>> | <<<ear:generateApplicationXml>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<process-resources>>> | <<<resources:resources>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<package>>> | <<<ear:ear>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<install>>> | <<<install:install>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<deploy>>> | <<<deploy:deploy>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
- This project instance can be used by the mojo to obtain results, and
propogate any changes it sees fit into the
- original build.
+ <<Default Lifecycle Bindings - maven-plugin Packaging>>
- Finally, when forking the new lifecycle, it is possible to augment it on top
of the changes already made by the
- packaging and the plugins in the POM.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<generate-resources>>> | <<<plugin:descriptor>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<process-resources>>> | <<<resources:resources>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<compile>>> | <<<compiler:compile>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<process-test-resources>>> | <<<resources:testResource>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<test-compile>>> | <<<compiler:testCompile>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<test>>> | <<<surefire:test>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<package>>> | <<<jar:jar>>> <and>
<<<plugin:addPluginArtifactMetadata>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<install>>> | <<<install:install>>> <and>
<<<plugin:updateRegistry>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<deploy>>> | <<<deploy:deploy>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
- For example, consider the Clover plugin. If <<<clover:check>>> were to be
run from the command line, the plugin
- would need to fork the lifecycle, executing the <<<test>>> phase. But, it
would also need to add some configuration
- and bind the <<<clover:compiler>>> goal to the <<<generate-sources>>> phase.
+ <<Default Lifecycle Bindings - POM Packaging>>
- This can be achieved by including the following file as
<<<META-INF/maven/lifecycle.xml>>> in the plugin JAR:
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<package>>> | <<<site:attach-descriptor>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<install>>> | <<<install:install>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<deploy>>> | <<<deploy:deploy>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
-----
-<lifecycles>
- <lifecycle>
- <id>clover</id>
- <phases>
- <phase>
- <id>generate-sources</id>
- <executions>
- <execution>
- <configuration>
- <debug>true</debug>
- </configuration>
- <goals>
- <goal>compiler</goal>
- </goals>
- </execution>
- </executions>
- </phase>
- </phases>
- </lifecycle>
-</lifecycles>
-----
+ <<Site Lifecycle Bindings>>
- Here, the <<<executions>>> element is present in a similar way to a plugin
declaration in the POM. This can be used
- to bind a goal one or more times to a particular phase, as well as
specifying configuration. Note that configuration
- already provided in the POM to that plugin that is not part of a specific
execution will also be applied.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<site>>> | <<<site:site>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<site-deploy>>> | <<<site:deploy>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
- The lifecycle ID given here (<<<clover>>>) can then be used in the mojo to
specify what to overlay on the forked
- lifecycle when executing it, using the following mojo level declaration:
+ <<References>>
-----
[EMAIL PROTECTED] phase="test" lifecycle="clover"
-----
+ The full Maven lifecycle is defined
+
{{{http://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/maven-core/src/main/resources/META-INF/plexus/components.xml}here}}
for Maven 2.0.x
+ and
{{{http://svn.apache.org/repos/asf/maven/components/trunk/maven-core/src/main/resources/META-INF/plexus/components.xml}here}}
for Maven 2.1.x.
+ <{{{introduction-to-the-lifecycle.html}[top]}}.>
