I have made some of the changes in the attached file.
There is not much that can be done until the plugin definition is added.
This definition will clarify a few things and may make it easier to fix
some of the other things.
There are sentences like this one:
" The second way to add goals to phases is to configure plugins in your
project. Plugins are artifacts that provide
goals to Maven."
that is written from an odd point of view.
If I am a Java developer, why would adding more goals be something that
I want to do?
Each entire sections should be written from a developers point of view.
Rather than adding goals, I may want to perform some special processing
during the build.
This may require the configuration of additional plugins which in turn
might get activated by invoking additional goals (or not).
As a Java developer, I can not add goals unless the goals are part of
the plugin and I would only add goals
a) if the goals were not already in the standard maven build flow AND
b) the goal is available in the plugin.
I suspect that this is a common problem with the Introductory
documentation that makes it hard for a Java developer to read.
Can someone suggest a description of "plugin" and "Mojo" that is written
from a developer's point of view but sufficiently close to the technical
reality that it will not cause trouble when someone starts to read the
Plugin Developer's sections.
Ron
On 09/12/2014 11:42 AM, Ron Wheeler wrote:
After using maven for 7+years, I decided that I finally knew enough
about it to read the docs.
I started here -
http://maven.apache.org/guides/getting-started/index.html - and this
led to other pages.
I have found some places where a little cleaning up might help new users.
There is one BIG issue and a few smaller ones.
1)
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
1a)
"Packaging
The first, and most common way, is to set the packaging for your
project via the equally named POM element <packaging>. Some of the
valid packaging values are jar, war, ear and pom.
"
Could we have the full list here or a link to a page with the full
list of the "normal" ones?
Could we have a mention that plug-ins can provide new packaging. There
is an example after the table of the Plexus. This discussion would be
better if held together rather than split up with a discussion of
binding and a table between the two parts of the story.
1b) In the table following this line "Each packaging contains a list
of goals to bind to a particular phase. For example, thejarpackaging
will bind the following goals to build phases of the default
lifecycle." a heading row would be nice.
1c)
Plugins are mentioned well before they are defined on the page. It
would be helpful to briefly describe what a plugin is before using it
as a known concept in "A Build Phase is Made Up of Plugin Goals" which
never defines it before dropping "And this is done by declaring the
plugin goals bound to those build phases."
1d)
The definition of plug-in is obscure to say the least "Plugins are
artifacts that provide goals to Maven." Surely there must be a clearer
way to describe the concept of plugin.
This is one of the most important Maven concepts and this is a WTF
definition.
2) http://maven.apache.org/guides/getting-started/index.html
2a)How can Maven benefit my development process? -> How can Maven be
of benefit to my development process? -> How can Maven improve my
development process?
More common English usage although the current wording is not wrong
2b) How do I use plug-ins? -> How do I use plugins? no hyphen in
plug-in. Whoops plugin!
2c) How do I use plugins? has no description of what a plugin is.
3) http://maven.apache.org/guides/mini/guide-configuring-plugins.html
3a) No definition of what a plugin is; it just starts of with the
assertion that there are 2 types. I am not sure that that statement is
really true or if it is, it is not a very useful categorization.
3b) It is recommended to always defined each version of the plugins
used by the build to guarantee the build reproducibility. -> It is
recommended the version of the each plugins used by the build is
specified to guarantee the reproducibility of the build.
A good practice is to specify them in
the<build><pluginManagement/></build>elements for*each*build plugins
(generally, you will define a <pluginManagement/> element in a parent
POM). ->
It is a good practice to specify the version in
the<build><pluginManagement/></build>element for*each*plugin. The
<pluginManagement/> element is generally specified in a parent POM so
that the same plugin version is use in all related projects.
c) "Maven plugins (build and reporting) are configured by specifying
a<configuration>element where the child elements of
the<configuration>element are mapped to fields, or setters, inside
your Mojo (remember that a plug-in consists of one or more Mojos where
a Mojo maps to a goal). "
Remember!!!. This is the first time a Mojo has been mentioned. It has
no definition and if I look it up I get:
"mo·jo1
'mojo/
nounUS
a magic charm, talisman, or spell.
"someone must have their mojo working over at the record company"
magic power.
synonyms: magic, voodoo, hoodoo, wizardry, sorcery;
"
No wonder my builds aren't working!
Can these be fixed soon.
Some of them are just little bugs but the lack of a clear definition
and discussion of plugins at the beginning of the "Getting Started"
documentation is a really big oversight since so much of Maven depends
on the built-in plugins and plugins that are created for special tasks.
Now that we have a new logo and persona, it is time to fix the docs to
make them more accessible.
Is there a chance that I may eventually understand Maven!
Ron
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
------
Introduction to the Build Lifecycle
------
Brett Porter
------
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/doxia/references/apt-format.html
Introduction to the Build Lifecycle
* Table Of Contents
* {{{Build_Lifecycle_Basics}Build Lifecycle Basics}}
* {{{Setting_Up_Your_Project_to_Use_the_Build_Lifecycle}Setting Up Your
Project to Use the Build Lifecycle}}
* {{{Packaging}Packaging}}
* {{{Plugins}Plugins}}
* {{{Lifecycle_Reference}Lifecycle Reference}}
* {{{Built-in_Lifecycle_Bindings}Built-in Lifecycle Bindings}}
[]
* {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 (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 {{{./introduction-to-the-pom.html}POM}} will ensure
they get the results they desired.
There are three built-in build lifecycles:
* <<<default>>> - Handles your project deployment
* <<<clean>>> - Handles project cleaning
* <<<site>>> - Handles the creation of your project's site documentation
** {A Build Lifecycle is Made Up of Phases}
Each of these build lifecycles is 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 {{{Lifecycle_Reference}Lifecycle Reference}}):
* <<<validate>>> - validate the project is correct and all necessary
information is available
* <<<compile>>> - compile the source code of the project
* <<<test>>> - test the compiled source code using a suitable unit testing
framework. These tests should not
require the code be packaged or deployed
* <<<package>>> - take the compiled code and package it in its
distributable format, such as a JAR.
* <<<integration-test>>> - process and deploy the package if necessary into
an environment where integration tests
can be run
* <<<verify>>> - run any checks to verify the package is valid and meets
quality criteria
* <<<install>>> - install the package into the local repository, for use as
a dependency in other projects locally
* <<<deploy>>> - done in an integration or release environment, copies the
final package to the remote repository
for sharing with other developers and projects.
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.
To do all those, you only need to call the last build phase to be executed,
in this case, <<<deploy>>>:
-------
mvn deploy
-------
This is used 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>>>, etc.), 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 (i.e. a project with one or more
subprojects). For example:
------
mvn clean install
------
This command will traverse into all of the subprojects and run <<<clean>>>,
then <<<install>>> (including all of
the prior steps).
<{{{./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. 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 be bound to zero or more build phases. A goal that is 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 <<<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 be executed first
(meaning it will run all of the preceding phases of the clean lifecycle,
plus the <<<clean>>> phase itself), and then the
<<<dependency:copy-dependencies>>> goal, before finally executing the
<<<package>>> phase (and all its preceding build phases of the default
lifecycle).
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: 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>).
<{{{./introduction-to-the-lifecycle.html}[top]}}.>
* {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}
The first, and most common way, is to set the packaging for your project via
the equally named POM element <<<\<packaging\>>>>. Some of the valid
packaging values are <<<jar>>>, <<<war>>>, <<<ear>>> and <<<pom>>>. If no
packaging value has been specified, it will default
to <<<jar>>>.
Note that some packaging types are only availableif you include a particular
plugin in the
<<<\<build\>>>> section of your POM and specify
<<<\<extensions\>true\</extensions\>>>> for that plugin.
One example of a plugin that requires this is the Plexus plugin, which
provides a <<<plexus-application>>> and
<<<plexus-service>>> packaging.
Each packaging contains a list of goals to bind to a particular phase. For
example, the <<<jar>>> packaging will bind the following
goals to build phases of the default lifecycle.
*------------------------------+---------------------------------------------------------------------------------------+
| <<<Goals>>> | <<<Build Phase>>>
*------------------------------+---------------------------------------------------------------------------------------+
| <<<process-resources>>> | <<<resources:resources>>>
*------------------------------+---------------------------------------------------------------------------------------+
| <<<compile>>> | <<<compiler:compile>>>
*------------------------------+---------------------------------------------------------------------------------------+
| <<<process-test-resources>>> | <<<resources:testResources>>>
*------------------------------+---------------------------------------------------------------------------------------+
| <<<test-compile>>> | <<<compiler:testCompile>>>
*------------------------------+---------------------------------------------------------------------------------------+
| <<<test>>> | <<<surefire:test>>>
*------------------------------+---------------------------------------------------------------------------------------+
| <<<package>>> | <<<jar:jar>>>
*------------------------------+---------------------------------------------------------------------------------------+
| <<<install>>> | <<<install:install>>>
*------------------------------+---------------------------------------------------------------------------------------+
| <<<deploy>>> | <<<deploy:deploy>>>
*------------------------------+---------------------------------------------------------------------------------------+
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 <<<pom>>>) binds goals obly to
the <<<install>>> and <<<deploy>>> phases (for a
complete list of goal-to-build-phase bindings of some of the packaging types,
refer to the
{{{Lifecycle_Reference}Lifecycle Reference}}).
<{{{./introduction-to-the-lifecycle.html}[top]}}.>
** {Plugins}
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: <<<compile>>> and
<<<testCompile>>>. The former
compiles the source code of your main code, while the later compiles the
source code of your test code.
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.
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 binds by default its goal <<<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\>>>>:
----
...
<plugin>
<groupId>org.codehaus.modello</groupId>
<artifactId>modello-maven-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<configuration>
<models>
<model>src/main/mdo/maven.mdo</model>
</models>
<version>4.0.0</version>
</configuration>
<goals>
<goal>java</goal>
</goals>
</execution>
</executions>
</plugin>
...
----
You might be wondering why that <<<\<executions\>>>> 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.
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.
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 <<<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>display-maven-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<phase>process-test-resources</phase>
<goals>
<goal>time</goal>
</goals>
</execution>
</executions>
</plugin>
...
----
<{{{./introduction-to-the-lifecycle.html}[top]}}.>
* {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.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<initialize>>> | initialize build state, e.g. set properties
or create directories.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<generate-sources>>> | generate any source code for inclusion in
compilation.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<process-sources>>> | process the source code, for example to
filter any values.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<generate-resources>>> | generate resources for inclusion in the
package.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<process-resources>>> | copy and process the resources into the
destination directory, ready for packaging.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<compile>>> | compile the source code of the project.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<process-classes>>> | post-process the generated files from
compilation, for example to do bytecode enhancement on Java classes.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<generate-test-sources>>> | generate any test source code for inclusion
in compilation.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<process-test-sources>>> | process the test source code, for example to
filter any values.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<generate-test-resources>>> | create resources for testing.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<process-test-resources>>> | copy and process the resources into the test
destination directory.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<test-compile>>> | compile the test source code into the test
destination directory
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<process-test-classes>>> | post-process the generated files from test
compilation, for example to do bytecode enhancement on Java classes. For Maven
2.0.5 and above.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<test>>> | run tests using a suitable unit testing
framework. These tests should not require the code be packaged or deployed.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<prepare-package>>> | 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)
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<package>>> | take the compiled code and package it in its
distributable format, such as a JAR.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<pre-integration-test>>> | perform actions required before integration
tests are executed. This may involve things such as setting up the required
environment.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<integration-test>>> | process and deploy the package if necessary
into an environment where integration tests can be run.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<post-integration-test>>> | perform actions required after integration
tests have been executed. This may including cleaning up the environment.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<verify>>> | run any checks to verify the package is valid
and meets quality criteria.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<install>>> | install the package into the local
repository, for use as a dependency in other projects locally.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<deploy>>> | done in an integration or release
environment, copies the final package to the remote repository for sharing with
other developers and projects.
*-------------------------------+--------------------------------------------------------------------------------------+
<<Site Lifecycle>>
*-------------------------------+--------------------------------------------------------------------------------------+
| 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
*-------------------------------+--------------------------------------------------------------------------------------+
<{{{./introduction-to-the-lifecycle.html}[top]}}.>
* {Built-in Lifecycle Bindings}
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.
** Clean Lifecycle Bindings
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<clean>>> | <<<clean:clean>>>
*-------------------------------+--------------------------------------------------------------------------------------+
** Default Lifecycle Bindings - Packaging <<<ejb>>> / <<<ejb3>>> / <<<jar>>> /
<<<par>>> / <<<rar>>> / <<<war>>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<process-resources>>> | <<<resources:resources>>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<compile>>> | <<<compiler:compile>>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<process-test-resources>>> | <<<resources:testResources>>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<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>>>
*-------------------------------+--------------------------------------------------------------------------------------+
** Default Lifecycle Bindings - Packaging <<<ear>>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<generate-resources>>> | <<<ear:generateApplicationXml>>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<process-resources>>> | <<<resources:resources>>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<package>>> | <<<ear:ear>>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<install>>> | <<<install:install>>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<deploy>>> | <<<deploy:deploy>>>
*-------------------------------+--------------------------------------------------------------------------------------+
** Default Lifecycle Bindings - Packaging <<<maven-plugin>>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<generate-resources>>> | <<<plugin:descriptor>>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<process-resources>>> | <<<resources:resources>>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<compile>>> | <<<compiler:compile>>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<process-test-resources>>> | <<<resources:testResources>>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<test-compile>>> | <<<compiler:testCompile>>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<test>>> | <<<surefire:test>>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<package>>> | <<<jar:jar>>> <and>
<<<plugin:addPluginArtifactMetadata>>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<install>>> | <<<install:install>>> <and>
<<<plugin:updateRegistry>>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<deploy>>> | <<<deploy:deploy>>>
*-------------------------------+--------------------------------------------------------------------------------------+
** Default Lifecycle Bindings - Packaging <<<pom>>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<package>>> | <<<site:attach-descriptor>>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<install>>> | <<<install:install>>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<deploy>>> | <<<deploy:deploy>>>
*-------------------------------+--------------------------------------------------------------------------------------+
** Site Lifecycle Bindings
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<site>>> | <<<site:site>>>
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<site-deploy>>> | <<<site:deploy>>>
*-------------------------------+--------------------------------------------------------------------------------------+
** References
The full Maven lifecycle is defined by the file <<<components.xml>>> in the
module <<<maven-core>>> and viewable from SVN in the branches for
{{{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}}
and
{{{http://svn.apache.org/repos/asf/maven/maven-3/trunk/maven-core/src/main/resources/META-INF/plexus/components.xml}Maven
3.0.x}}.
<{{{./introduction-to-the-lifecycle.html}[top]}}.>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
