maven-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From vsive...@apache.org
Subject svn commit: r610629 - /maven/site/trunk/src/site/apt/guides/introduction/introduction-to-the-lifecycle.apt
Date Thu, 10 Jan 2008 01:18:24 GMT
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:
-
-----
-@phase 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>>
 
-----
-@execute 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>>
 
-----
-@execute 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]}}.>



Mime
View raw message