You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maven.apache.org by bu...@apache.org on 2013/04/27 09:29:25 UTC
svn commit: r860084 [18/39] - in /websites/staging/maven/trunk/content: ./
background/ developers/ developers/conventions/ developers/release/
developers/website/ docs/2.0.1/ docs/2.0.10/ docs/2.0.11/ docs/2.0.2/
docs/2.0.3/ docs/2.0.4/ docs/2.0.5/ doc...
Modified: websites/staging/maven/trunk/content/guides/introduction/introduction-to-plugin-registry.html
==============================================================================
--- websites/staging/maven/trunk/content/guides/introduction/introduction-to-plugin-registry.html (original)
+++ websites/staging/maven/trunk/content/guides/introduction/introduction-to-plugin-registry.html Sat Apr 27 07:29:22 2013
@@ -1,6 +1,6 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!--
- | Generated by Apache Maven Doxia at Apr 23, 2013
+ | Generated by Apache Maven Doxia at Apr 27, 2013
| Rendered using Apache Maven Stylus Skin 1.5
-->
<html xmlns="http://www.w3.org/1999/xhtml">
@@ -13,7 +13,7 @@
</style>
<link rel="stylesheet" href="../../css/print.css" type="text/css" media="print" />
<meta name="author" content="John Casey" />
- <meta name="Date-Revision-yyyymmdd" content="20130423" />
+ <meta name="Date-Revision-yyyymmdd" content="20130427" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"></script>
@@ -43,7 +43,7 @@
Introduction to the Plugin Registry
</div>
<div class="xright">
- Last Published: 2013-04-23
+ Last Published: 2013-04-27
</div>
<div class="clear">
<hr/>
@@ -231,7 +231,69 @@
</div>
<div id="bodyColumn">
<div id="contentBox">
- <div class="section"><h2>Introduction to the Plugin Registry<a name="Introduction_to_the_Plugin_Registry"></a></h2><p>The Maven 2 plugin registry (~/.m2/plugin-registry.xml) is a mechanism to help the user exert some control over their build environment. Rather than simply fetching the latest version of every plugin used in a given build, this registry allows the user to peg a plugin to a particular version, and only update to newer versions under certain restricted circumstances. There are various ways to configure or bypass this feature, and the feature itself can be managed on either a per-user or global level.</p><div class="section"><h3><b>Warning!</b><a name="Warning"></a></h3><p>The plugin registry is currently in a semi-dormant state within Maven 2. This is because it has been shown to have some subtle behavior that is not quite intuitive. While we believe it's important to allow the user to pin down which version of a particular plugin is used across all bui
lds, it's not clear that this type of information should be machine-specific (i.e. tied to something outside the project directory).</p><p>Users should be cautious when attempting to use the <tt>plugin-registry.xml</tt>. Redesign of this feature in upcoming 2.1 and/or 2.2 is likely.</p><p>For now, Maven <i>should</i> keep using the same version of a plugin - assuming a different version is not specified in the POM - until the user chooses to run with the <tt>-U</tt> option explicitly enabled.</p></div><div class="section"><h3>A Tour of plugin-registry.xml<a name="A_Tour_of_plugin-registry.xml"></a></h3><p>The plugin registry file (per-user: ~/.m2/plugin-registry.xml, global: $M2_HOME/conf/plugin-registry.xml) contains a set of plugin-version registrations, along with some configuration parameters for the registry itself.</p><p>Currently, the plugin registry supports configuration options for the following:</p><ul><li><b>updateInterval</b> - Determines how often (or whether)
the registered plugins are checked for updates.<p>Combined with the <b>lastChecked</b> plugin attribute, this determines whether a particular plugin will be checked for updates during a given build. Valid settings are: never, always, and interval:TTT (TTT is a short specification for a time interval, which follows the pattern /([0-9]+[wdhm])+/). Intervals are specified down to the minute resolution. An example of an interval specification might be:</p><p><tt>interval:4w2h30m</tt> (check every 4 weeks, 2 hours, and 30 minutes)</p></li><li><b>autoUpdate</b> - Specifies whether the user should be prompted before registering plugin-version updates. This is a boolean value, accepting true/false.</li><li><b>checkLatest</b> - Specifies whether the LATEST artifact metadata should be consulted while determining versions for <i>unregistered</i> plugins.<p>LATEST metadata is always published when a plugin is installed or deployed to a repository, and so will always reference the newest
copy of the plugin, regardless of whether this is a snapshot version or not.</p><p><i>NOTE:</i> Registered plugins will currently only ever be updated with the results of RELEASE metadata resolution.</p><p>Obviously, the plugin registry also contains information about resolved plugin versions. The following information is tracked for each registered plugin:</p></li><li><b>groupId</b> - The plugin's group id.</li><li><b>artifactId</b> - The plugin's artifact id.</li><li><b>lastChecked</b> - The timestamp from the last time updates were checked for this plugin.</li><li><b>useVersion</b> - The currently registered version for this plugin. This is the version Maven will use when executing this plugin's mojos.</li><li><b>rejectedVersions</b> - A list of versions discovered for this plugin which have been rejected by the user. This keeps Maven from continually prompting the user to update a given plugin to the same new version.</li></ul></div><div class="section"><h3>Using (or no
t) the Plugin Registry<a name="Using_or_not_the_Plugin_Registry"></a></h3><p>There are many ways you can override the default plugin registry settings. Often, this will be desirable for a single, one-off build of a project that deviates from your normal environment configuration. However, before discussing these options, it's important to understand how the plugin registry resolves versions for unregistered plugins, along with plugins in need of an update check.</p><div class="section"><h4>Resolving Plugin Versions<a name="Resolving_Plugin_Versions"></a></h4><p>The plugin registry uses a relatively straightforward algorithm for resolving plugin versions. However, considerations for when to check, when to prompt the user, and when to persist resolved plugin versions complicate this implementation considerably. In general, plugin versions are resolved using a four-step process:</p><ol style="list-style-type: decimal"><li>Check for a plugin configuration in the MavenProject ins
tance. Any plugin configuration found in the MavenProject is treated as authoritative, and will stop the plugin-version resolution/persistence process when found.</li><li>If the plugin registry is enabled, check it for an existing registered version. If the plugin has been registered, a combination of the updateInterval configuration and the lastChecked attribute (on the plugin) determine whether the plugin needs to be checked for updates. If the plugin doesn't need an update check, the registered version is used.<p>If the plugin is due for an update check, the plugin-artifact's RELEASE metadata is resolved. Resolution of this metadata may trigger a prompt to notify the user of the new version, and/or persistence of the new version in the registry. If the update is performed, the lastChecked attribute is updated to reflect this.</p></li><li><i>If</i> the <b>checkLatest</b> configuration is set to <tt>true</tt>, or the <tt>'--check-plugin-latest'</tt> CLI option (discussed la
ter) is provided, then the LATEST artifact metadata is resolved for the plugin.<p>If this metadata is resolved successfully, that version is used. This may trigger a prompt to ask the user whether to register the plugin, and a successive persistence step for the new plugin version.</p></li><li>If the version still has not been resolved, RELEASE artifact metadata is checked for the plugin. If this metadata resolves successfully, it is the version used. This may also trigger a prompt to ask the user whether to register the plugin, and a persistence step registering the new plugin version.<p>I've alluded to prompting the user and persisting the plugin version into the registry. Now, let's examine the circumstances under which these steps actually take place.</p><p>There are two cases where the user may be prompted to change the plugin registry; when the plugin is not registered, and when the plugin is registered, but an updated version is discovered. By default, the user is pro
mpted to save the resolved version for each plugin, with the option of specifying that a decision should be remembered and applied to all (either yes to all, or no to all) plugins registry updates. However, it is also possible to bypass this behavior in the following ways:</p><ul><li>Specify <b>autoUpdate</b> == <tt>true</tt> in the plugin-registry.xml. This configuration parameter means that the user is not prompted, and all updated/discovered versions are to be persisted.</li><li>Specify <tt>'--batch-mode'</tt> (or <tt>'-B'</tt>) from the command line. This functions in the same way as the <b>autoUpdate</b> config parameter above.</li><li>Specify <tt>'--no-plugin-updates'</tt> | <tt>'-npu'</tt> from the command line. This prevents any updates or new registrations from taking place, but existing plugin versions in the registry will be used when available.</li><li>Specify <tt>'--check-plugin-updates'</tt> | <tt>'--update-plugins'</tt> | <tt>'-up'</tt> | <tt>'-cpu'</tt> (syno
nyms) from the command line.</li><li>Specify <tt>'--no-plugin-registry'</tt> | <tt>'-npr'</tt> from the command line. This prevents resolution of plugin versions using the plugin-registry.xml file. The plugin version will be resolved either from the project or from the repository in this case.</li><li>Specify <b>usePluginRegistry</b> == <tt>false</tt> in the settings.xml. This configuration parameter will disable use of the plugin registry for the entire build environment, as opposed to the immediate build execution (as in the case of the corresponding command line switch above).<p>These force all registered plugins to be updated. The user will still be prompted to approve plugin versions, unless one of the above switches is also provided.</p></li></ul></li></ol></div><div class="section"><h4>Summary of Command Line Options for the Plugin Registry<a name="Summary_of_Command_Line_Options_for_the_Plugin_Registry"></a></h4><p>The following summary of command line options is pro
vided for quick reference:</p><ul><li><tt>--no-plugin-registry</tt> - Bypass the plugin registry.<p><i>Synonym:</i> <tt>-npr</tt></p></li><li><tt>--no-plugin-latest</tt> - Don't check the LATEST artifact metadata when resolving plugin versions, regardless of the value of <b>useLatest</b> in the plugin-registry.xml file.<p><i>Synonym:</i> <tt>-npl</tt></p></li><li><tt>--check-plugin-latest</tt> - Check the LATEST artifact metadata when resolving plugin versions, regardless of the value of <b>useLatest</b> in the plugin-registry.xml file.<p><i>Synonym:</i> <tt>-cpl</tt></p></li><li><tt>--no-plugin-updates</tt> - Do not search for updated versions of registered plugins. Only use the repository to resolve unregistered plugins.<p><i>Synonym:</i> <tt>-npu</tt></p></li><li><tt>--check-plugin-updates</tt> - Force the plugin version manager to check for updated versions of any registered plugins, currently using RELEASE metadata <b>only</b>.<p><i>Synonyms:</i> <tt>--update-plugins</t
t> <tt>-up</tt> <tt>-cpu</tt></p></li></ul></div></div></div>
+ <div class="section">
+<h2>Introduction to the Plugin Registry<a name="Introduction_to_the_Plugin_Registry"></a></h2>
+<p>The Maven 2 plugin registry (~/.m2/plugin-registry.xml) is a mechanism to help the user exert some control over their build environment. Rather than simply fetching the latest version of every plugin used in a given build, this registry allows the user to peg a plugin to a particular version, and only update to newer versions under certain restricted circumstances. There are various ways to configure or bypass this feature, and the feature itself can be managed on either a per-user or global level.</p>
+<div class="section">
+<h3><b>Warning!</b><a name="Warning"></a></h3>
+<p>The plugin registry is currently in a semi-dormant state within Maven 2. This is because it has been shown to have some subtle behavior that is not quite intuitive. While we believe it's important to allow the user to pin down which version of a particular plugin is used across all builds, it's not clear that this type of information should be machine-specific (i.e. tied to something outside the project directory).</p>
+<p>Users should be cautious when attempting to use the <tt>plugin-registry.xml</tt>. Redesign of this feature in upcoming 2.1 and/or 2.2 is likely.</p>
+<p>For now, Maven <i>should</i> keep using the same version of a plugin - assuming a different version is not specified in the POM - until the user chooses to run with the <tt>-U</tt> option explicitly enabled.</p></div>
+<div class="section">
+<h3>A Tour of plugin-registry.xml<a name="A_Tour_of_plugin-registry.xml"></a></h3>
+<p>The plugin registry file (per-user: ~/.m2/plugin-registry.xml, global: $M2_HOME/conf/plugin-registry.xml) contains a set of plugin-version registrations, along with some configuration parameters for the registry itself.</p>
+<p>Currently, the plugin registry supports configuration options for the following:</p>
+<ul>
+<li><b>updateInterval</b> - Determines how often (or whether) the registered plugins are checked for updates.
+<p>Combined with the <b>lastChecked</b> plugin attribute, this determines whether a particular plugin will be checked for updates during a given build. Valid settings are: never, always, and interval:TTT (TTT is a short specification for a time interval, which follows the pattern /([0-9]+[wdhm])+/). Intervals are specified down to the minute resolution. An example of an interval specification might be:</p>
+<p><tt>interval:4w2h30m</tt> (check every 4 weeks, 2 hours, and 30 minutes)</p></li>
+<li><b>autoUpdate</b> - Specifies whether the user should be prompted before registering plugin-version updates. This is a boolean value, accepting true/false.</li>
+<li><b>checkLatest</b> - Specifies whether the LATEST artifact metadata should be consulted while determining versions for <i>unregistered</i> plugins.
+<p>LATEST metadata is always published when a plugin is installed or deployed to a repository, and so will always reference the newest copy of the plugin, regardless of whether this is a snapshot version or not.</p>
+<p><i>NOTE:</i> Registered plugins will currently only ever be updated with the results of RELEASE metadata resolution.</p>
+<p>Obviously, the plugin registry also contains information about resolved plugin versions. The following information is tracked for each registered plugin:</p></li>
+<li><b>groupId</b> - The plugin's group id.</li>
+<li><b>artifactId</b> - The plugin's artifact id.</li>
+<li><b>lastChecked</b> - The timestamp from the last time updates were checked for this plugin.</li>
+<li><b>useVersion</b> - The currently registered version for this plugin. This is the version Maven will use when executing this plugin's mojos.</li>
+<li><b>rejectedVersions</b> - A list of versions discovered for this plugin which have been rejected by the user. This keeps Maven from continually prompting the user to update a given plugin to the same new version.</li></ul></div>
+<div class="section">
+<h3>Using (or not) the Plugin Registry<a name="Using_or_not_the_Plugin_Registry"></a></h3>
+<p>There are many ways you can override the default plugin registry settings. Often, this will be desirable for a single, one-off build of a project that deviates from your normal environment configuration. However, before discussing these options, it's important to understand how the plugin registry resolves versions for unregistered plugins, along with plugins in need of an update check.</p>
+<div class="section">
+<h4>Resolving Plugin Versions<a name="Resolving_Plugin_Versions"></a></h4>
+<p>The plugin registry uses a relatively straightforward algorithm for resolving plugin versions. However, considerations for when to check, when to prompt the user, and when to persist resolved plugin versions complicate this implementation considerably. In general, plugin versions are resolved using a four-step process:</p>
+<ol style="list-style-type: decimal">
+<li>Check for a plugin configuration in the MavenProject instance. Any plugin configuration found in the MavenProject is treated as authoritative, and will stop the plugin-version resolution/persistence process when found.</li>
+<li>If the plugin registry is enabled, check it for an existing registered version. If the plugin has been registered, a combination of the updateInterval configuration and the lastChecked attribute (on the plugin) determine whether the plugin needs to be checked for updates. If the plugin doesn't need an update check, the registered version is used.
+<p>If the plugin is due for an update check, the plugin-artifact's RELEASE metadata is resolved. Resolution of this metadata may trigger a prompt to notify the user of the new version, and/or persistence of the new version in the registry. If the update is performed, the lastChecked attribute is updated to reflect this.</p></li>
+<li><i>If</i> the <b>checkLatest</b> configuration is set to <tt>true</tt>, or the <tt>'--check-plugin-latest'</tt> CLI option (discussed later) is provided, then the LATEST artifact metadata is resolved for the plugin.
+<p>If this metadata is resolved successfully, that version is used. This may trigger a prompt to ask the user whether to register the plugin, and a successive persistence step for the new plugin version.</p></li>
+<li>If the version still has not been resolved, RELEASE artifact metadata is checked for the plugin. If this metadata resolves successfully, it is the version used. This may also trigger a prompt to ask the user whether to register the plugin, and a persistence step registering the new plugin version.
+<p>I've alluded to prompting the user and persisting the plugin version into the registry. Now, let's examine the circumstances under which these steps actually take place.</p>
+<p>There are two cases where the user may be prompted to change the plugin registry; when the plugin is not registered, and when the plugin is registered, but an updated version is discovered. By default, the user is prompted to save the resolved version for each plugin, with the option of specifying that a decision should be remembered and applied to all (either yes to all, or no to all) plugins registry updates. However, it is also possible to bypass this behavior in the following ways:</p>
+<ul>
+<li>Specify <b>autoUpdate</b> == <tt>true</tt> in the plugin-registry.xml. This configuration parameter means that the user is not prompted, and all updated/discovered versions are to be persisted.</li>
+<li>Specify <tt>'--batch-mode'</tt> (or <tt>'-B'</tt>) from the command line. This functions in the same way as the <b>autoUpdate</b> config parameter above.</li>
+<li>Specify <tt>'--no-plugin-updates'</tt> | <tt>'-npu'</tt> from the command line. This prevents any updates or new registrations from taking place, but existing plugin versions in the registry will be used when available.</li>
+<li>Specify <tt>'--check-plugin-updates'</tt> | <tt>'--update-plugins'</tt> | <tt>'-up'</tt> | <tt>'-cpu'</tt> (synonyms) from the command line.</li>
+<li>Specify <tt>'--no-plugin-registry'</tt> | <tt>'-npr'</tt> from the command line. This prevents resolution of plugin versions using the plugin-registry.xml file. The plugin version will be resolved either from the project or from the repository in this case.</li>
+<li>Specify <b>usePluginRegistry</b> == <tt>false</tt> in the settings.xml. This configuration parameter will disable use of the plugin registry for the entire build environment, as opposed to the immediate build execution (as in the case of the corresponding command line switch above).
+<p>These force all registered plugins to be updated. The user will still be prompted to approve plugin versions, unless one of the above switches is also provided.</p></li></ul></li></ol></div>
+<div class="section">
+<h4>Summary of Command Line Options for the Plugin Registry<a name="Summary_of_Command_Line_Options_for_the_Plugin_Registry"></a></h4>
+<p>The following summary of command line options is provided for quick reference:</p>
+<ul>
+<li><tt>--no-plugin-registry</tt> - Bypass the plugin registry.
+<p><i>Synonym:</i> <tt>-npr</tt></p></li>
+<li><tt>--no-plugin-latest</tt> - Don't check the LATEST artifact metadata when resolving plugin versions, regardless of the value of <b>useLatest</b> in the plugin-registry.xml file.
+<p><i>Synonym:</i> <tt>-npl</tt></p></li>
+<li><tt>--check-plugin-latest</tt> - Check the LATEST artifact metadata when resolving plugin versions, regardless of the value of <b>useLatest</b> in the plugin-registry.xml file.
+<p><i>Synonym:</i> <tt>-cpl</tt></p></li>
+<li><tt>--no-plugin-updates</tt> - Do not search for updated versions of registered plugins. Only use the repository to resolve unregistered plugins.
+<p><i>Synonym:</i> <tt>-npu</tt></p></li>
+<li><tt>--check-plugin-updates</tt> - Force the plugin version manager to check for updated versions of any registered plugins, currently using RELEASE metadata <b>only</b>.
+<p><i>Synonyms:</i> <tt>--update-plugins</tt> <tt>-up</tt> <tt>-cpu</tt></p></li></ul></div></div></div>
</div>
</div>
<div class="clear">
Modified: websites/staging/maven/trunk/content/guides/introduction/introduction-to-plugin-resolution.html
==============================================================================
--- websites/staging/maven/trunk/content/guides/introduction/introduction-to-plugin-resolution.html (original)
+++ websites/staging/maven/trunk/content/guides/introduction/introduction-to-plugin-resolution.html Sat Apr 27 07:29:22 2013
@@ -1,6 +1,6 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!--
- | Generated by Apache Maven Doxia at Apr 23, 2013
+ | Generated by Apache Maven Doxia at Apr 27, 2013
| Rendered using Apache Maven Stylus Skin 1.5
-->
<html xmlns="http://www.w3.org/1999/xhtml">
@@ -14,7 +14,7 @@
<link rel="stylesheet" href="../../css/print.css" type="text/css" media="print" />
<meta name="author" content="John Casey" />
<meta name="Date-Creation-yyyymmdd" content="20090801" />
- <meta name="Date-Revision-yyyymmdd" content="20130423" />
+ <meta name="Date-Revision-yyyymmdd" content="20130427" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"></script>
@@ -44,7 +44,7 @@
Introduction to Maven Plugin Resolution
</div>
<div class="xright">
- Last Published: 2013-04-23
+ Last Published: 2013-04-27
</div>
<div class="clear">
<hr/>
@@ -232,14 +232,61 @@
</div>
<div id="bodyColumn">
<div id="contentBox">
- <!-- Licensed to the Apache Software Foundation (ASF) under one --><!-- or more contributor license agreements. See the NOTICE file --><!-- distributed with this work for additional information --><!-- regarding copyright ownership. The ASF licenses this file --><!-- to you 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/referen
ces/apt-format.html --><div class="section"><h2>Introduction: How Maven Resolves Plugins<a name="Introduction:_How_Maven_Resolves_Plugins"></a></h2><div class="section"><h3>Introduction<a name="Introduction"></a></h3><p>Starting with 2.0, Maven allows users to execute plugins that have not yet been installed. This new feature eliminates the need to maintain local plugin installations, and provides the implicit ability to instantly take advantage of new plugin releases. However, it also means that plugin information must be resolved at build time, which can be a complex task.</p><p>This document will detail the mechanism used to resolve plugin information.</p></div><div class="section"><h3>Referencing Plugins<a name="Referencing_Plugins"></a></h3><p>Maven 2.0 brings with it added flexibility for referencing plugins and their mojos. Since plugin information is determined at build time, plugin prefixes can be ambiguous, and dependent on an individual user's Maven configuration.
Therefore, in addition to the original mechanism of referencing a plugin by its shorthand prefix and a goal, Maven can also process plugin and mojo references that concretely specify groupId, artifactId, and optionally, version.</p><p>Most users will have little difficulty using Maven as before, referencing plugins by their prefix. However, with the introduction of the build lifecycle - and mojo bindings to that lifecycle - it is critical that lifecycle mappings be able to refer to a mojo in an unambiguous way. In fact, when dealing with lifecycle mappings, it's illegal to specify a mojo using its plugin-prefix. This helps Maven avoid the case where the 'jar' lifecycle behaves differently on two users' machines, simply due to their local Maven configurations. As a side effect of this requirement, users also have the option to specify plugins and mojos in this way from the command line.</p><p>For clarity, the following are the three ways to reference a mojo from the command
line. These will all result in the clean mojo of the maven-clean-plugin being invoked:</p><div class="source"><pre> mvn org.apache.maven.plugins:maven-clean-plugin:2.0:clean
+ <!-- Licensed to the Apache Software Foundation (ASF) under one --><!-- or more contributor license agreements. See the NOTICE file --><!-- distributed with this work for additional information --><!-- regarding copyright ownership. The ASF licenses this file --><!-- to you 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/referen
ces/apt-format.html --><div class="section">
+<h2>Introduction: How Maven Resolves Plugins<a name="Introduction:_How_Maven_Resolves_Plugins"></a></h2>
+<div class="section">
+<h3>Introduction<a name="Introduction"></a></h3>
+<p>Starting with 2.0, Maven allows users to execute plugins that have not yet been installed. This new feature eliminates the need to maintain local plugin installations, and provides the implicit ability to instantly take advantage of new plugin releases. However, it also means that plugin information must be resolved at build time, which can be a complex task.</p>
+<p>This document will detail the mechanism used to resolve plugin information.</p></div>
+<div class="section">
+<h3>Referencing Plugins<a name="Referencing_Plugins"></a></h3>
+<p>Maven 2.0 brings with it added flexibility for referencing plugins and their mojos. Since plugin information is determined at build time, plugin prefixes can be ambiguous, and dependent on an individual user's Maven configuration. Therefore, in addition to the original mechanism of referencing a plugin by its shorthand prefix and a goal, Maven can also process plugin and mojo references that concretely specify groupId, artifactId, and optionally, version.</p>
+<p>Most users will have little difficulty using Maven as before, referencing plugins by their prefix. However, with the introduction of the build lifecycle - and mojo bindings to that lifecycle - it is critical that lifecycle mappings be able to refer to a mojo in an unambiguous way. In fact, when dealing with lifecycle mappings, it's illegal to specify a mojo using its plugin-prefix. This helps Maven avoid the case where the 'jar' lifecycle behaves differently on two users' machines, simply due to their local Maven configurations. As a side effect of this requirement, users also have the option to specify plugins and mojos in this way from the command line.</p>
+<p>For clarity, the following are the three ways to reference a mojo from the command line. These will all result in the clean mojo of the maven-clean-plugin being invoked:</p>
+<div class="source">
+<pre> mvn org.apache.maven.plugins:maven-clean-plugin:2.0:clean
mvn org.apache.maven.plugins:maven-clean-plugin:clean
- mvn clean:clean</pre></div><p>By contrast, only the following are valid mojo references from inside a lifecycle mapping definition:</p><div class="source"><pre> org.apache.maven.plugins:maven-clean-plugin:2.0:clean
- org.apache.maven.plugins:maven-clean-plugin:clean</pre></div><p><b>NOTE:</b> It's probably bad form to pin a plugin reference to a specific version inside a lifecycle mapping definition, since this prevents the user from taking advantage of plugin updates.</p></div><div class="section"><h3>Resolving Plugin Information<a name="Resolving_Plugin_Information"></a></h3><p>Since users have the ability to reference a plugin by its groupId and artifactId <b>without</b> a version, Maven must have the ability to resolve the plugin's version given these other two attributes. However, since users can also refer to a plugin by its prefix, Maven must also have the ability to resolve a plugin by this prefix alone - including resolution of the plugin's version. To handle these two scenarios, Maven employs a two-stage process for resolving plugin information.</p><div class="section"><h4>Resolving <tt>groupId</tt> and <tt>artifactId</tt> for a Plugin<a name="Resolving_groupId_and_artifactId
_for_a_Plugin"></a></h4><p>Maven's approach to resolving a plugin's groupId and artifactId given its prefix is actually relatively simple. The user can specify a set of plugin groupId's to be searched. Using repository metadata for each configured groupId, Maven will search for plugin prefix mappings using the process detailed in [<a href="#a1">1</a>].</p></div><div class="section"><h4>Resolving a Plugin's Version<a name="Resolving_a_Plugins_Version"></a></h4><p>When a plugin's groupId and artifactId are known, but its version is still unknown, Maven will resolve that plugin's version using a variety of sources. It will check, in order, the following:</p><ol style="list-style-type: decimal"><li><i>the project's POM</i><p>This includes all plugins specified in the <build> section; this is intuitive. However, since all plugin specifications in the POM are still generally a better source of information than reverting to external sources, <b>the <pluginManagement> se
ction will also be searched.</b></p><p><b>NOTE:</b> Checking of the <pluginManagement> section is new for Maven 2.0.1.</p></li><li><i>the plugin registry</i><p>This configuration file, usually located in <tt>plugin-registry.xml</tt> within the $HOME/.m2 directory, is disabled by default. To enable it, add the following section to the <tt>settings.xml</tt> file (also within $HOME/.m2):</p><div class="source"><pre><settings>
+ mvn clean:clean</pre></div>
+<p>By contrast, only the following are valid mojo references from inside a lifecycle mapping definition:</p>
+<div class="source">
+<pre> org.apache.maven.plugins:maven-clean-plugin:2.0:clean
+ org.apache.maven.plugins:maven-clean-plugin:clean</pre></div>
+<p><b>NOTE:</b> It's probably bad form to pin a plugin reference to a specific version inside a lifecycle mapping definition, since this prevents the user from taking advantage of plugin updates.</p></div>
+<div class="section">
+<h3>Resolving Plugin Information<a name="Resolving_Plugin_Information"></a></h3>
+<p>Since users have the ability to reference a plugin by its groupId and artifactId <b>without</b> a version, Maven must have the ability to resolve the plugin's version given these other two attributes. However, since users can also refer to a plugin by its prefix, Maven must also have the ability to resolve a plugin by this prefix alone - including resolution of the plugin's version. To handle these two scenarios, Maven employs a two-stage process for resolving plugin information.</p>
+<div class="section">
+<h4>Resolving <tt>groupId</tt> and <tt>artifactId</tt> for a Plugin<a name="Resolving_groupId_and_artifactId_for_a_Plugin"></a></h4>
+<p>Maven's approach to resolving a plugin's groupId and artifactId given its prefix is actually relatively simple. The user can specify a set of plugin groupId's to be searched. Using repository metadata for each configured groupId, Maven will search for plugin prefix mappings using the process detailed in [<a href="#a1">1</a>].</p></div>
+<div class="section">
+<h4>Resolving a Plugin's Version<a name="Resolving_a_Plugins_Version"></a></h4>
+<p>When a plugin's groupId and artifactId are known, but its version is still unknown, Maven will resolve that plugin's version using a variety of sources. It will check, in order, the following:</p>
+<ol style="list-style-type: decimal">
+<li><i>the project's POM</i>
+<p>This includes all plugins specified in the <build> section; this is intuitive. However, since all plugin specifications in the POM are still generally a better source of information than reverting to external sources, <b>the <pluginManagement> section will also be searched.</b></p>
+<p><b>NOTE:</b> Checking of the <pluginManagement> section is new for Maven 2.0.1.</p></li>
+<li><i>the plugin registry</i>
+<p>This configuration file, usually located in <tt>plugin-registry.xml</tt> within the $HOME/.m2 directory, is disabled by default. To enable it, add the following section to the <tt>settings.xml</tt> file (also within $HOME/.m2):</p>
+<div class="source">
+<pre><settings>
...
<usePluginRegistry>true</usePluginRegistry>
...
-</settings></pre></div><p>The plugin registry will maintain a mapping of <a name="groupId_artifactId">groupId, artifactId</a> for a plugin to the version to be used. It will also maintain a record of the last time the plugin was checked for updated versions; the configuration for when to check for updated versions; and a list of rejected versions of the plugin which are not to be used. If an updated version is found which has not yet been rejected, the plugin version manager will ask the user whether to use this version. The user can reject the version for now or always, or accept it for now or always. If prompting is disabled (batch mode), the plugin registry can be configured with a default answer to this question.</p><p>See [<a href="#a2">2</a>] for more information on the plugin registry.</p><p>See [<a href="#a3">3</a>] for more information on the <tt>settings.xml</tt> file.</p></li><li><i>LATEST version metadata</i><p>This is published each time a Maven plugin is
deployed or installed. It is simply a pointer to the latest published version of the plugin. It differs from the SNAPSHOT metadata in that it is always present, regardless of the project's version.</p><p>If you use the plugin registry, you can disable this check.</p></li><li><i>RELEASE version metadata</i><p>Since the LATEST metadata is always published, it obsoletes this check when #3 is enabled. However, RELEASE metadata checking is still important in order to support legacy plugin-releases, where the LATEST metadata has not been published. This check can also be useful if the LATEST metadata check has been disabled. This might be used instead of LATEST metadata if the user only wants to use supported, released plugin versions.</p></li></ol><p>If all of the above resolution methods fail, the plugin cannot be located and an exception is thrown, stopping the build.</p></div></div><div class="section"><h3>Resources<a name="Resources"></a></h3><p><a name="a1">1</a>. <a href=".
/introduction-to-plugin-prefix-mapping.html">Introduction to the Plugin Prefix Mapping</a>.</p><p><a name="a2">2</a>. <a href="./introduction-to-plugin-registry.html">Introduction to the Plugin Registry</a>.</p><p><a name="a3">3</a>. <a href="../mini/guide-configuring-maven.html">Guide to Configuring Maven</a></p></div></div>
+</settings></pre></div>
+<p>The plugin registry will maintain a mapping of <a name="groupId_artifactId">groupId, artifactId</a> for a plugin to the version to be used. It will also maintain a record of the last time the plugin was checked for updated versions; the configuration for when to check for updated versions; and a list of rejected versions of the plugin which are not to be used. If an updated version is found which has not yet been rejected, the plugin version manager will ask the user whether to use this version. The user can reject the version for now or always, or accept it for now or always. If prompting is disabled (batch mode), the plugin registry can be configured with a default answer to this question.</p>
+<p>See [<a href="#a2">2</a>] for more information on the plugin registry.</p>
+<p>See [<a href="#a3">3</a>] for more information on the <tt>settings.xml</tt> file.</p></li>
+<li><i>LATEST version metadata</i>
+<p>This is published each time a Maven plugin is deployed or installed. It is simply a pointer to the latest published version of the plugin. It differs from the SNAPSHOT metadata in that it is always present, regardless of the project's version.</p>
+<p>If you use the plugin registry, you can disable this check.</p></li>
+<li><i>RELEASE version metadata</i>
+<p>Since the LATEST metadata is always published, it obsoletes this check when #3 is enabled. However, RELEASE metadata checking is still important in order to support legacy plugin-releases, where the LATEST metadata has not been published. This check can also be useful if the LATEST metadata check has been disabled. This might be used instead of LATEST metadata if the user only wants to use supported, released plugin versions.</p></li></ol>
+<p>If all of the above resolution methods fail, the plugin cannot be located and an exception is thrown, stopping the build.</p></div></div>
+<div class="section">
+<h3>Resources<a name="Resources"></a></h3>
+<p><a name="a1">1</a>. <a href="./introduction-to-plugin-prefix-mapping.html">Introduction to the Plugin Prefix Mapping</a>.</p>
+<p><a name="a2">2</a>. <a href="./introduction-to-plugin-registry.html">Introduction to the Plugin Registry</a>.</p>
+<p><a name="a3">3</a>. <a href="../mini/guide-configuring-maven.html">Guide to Configuring Maven</a></p></div></div>
</div>
</div>
<div class="clear">
Modified: websites/staging/maven/trunk/content/guides/introduction/introduction-to-plugins.html
==============================================================================
--- websites/staging/maven/trunk/content/guides/introduction/introduction-to-plugins.html (original)
+++ websites/staging/maven/trunk/content/guides/introduction/introduction-to-plugins.html Sat Apr 27 07:29:22 2013
@@ -1,6 +1,6 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!--
- | Generated by Apache Maven Doxia at Apr 23, 2013
+ | Generated by Apache Maven Doxia at Apr 27, 2013
| Rendered using Apache Maven Stylus Skin 1.5
-->
<html xmlns="http://www.w3.org/1999/xhtml">
@@ -13,7 +13,7 @@
</style>
<link rel="stylesheet" href="../../css/print.css" type="text/css" media="print" />
<meta name="author" content="John Casey" />
- <meta name="Date-Revision-yyyymmdd" content="20130423" />
+ <meta name="Date-Revision-yyyymmdd" content="20130427" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"></script>
@@ -43,7 +43,7 @@
Introduction to Maven 2.0 Plugin Development
</div>
<div class="xright">
- Last Published: 2013-04-23
+ Last Published: 2013-04-27
</div>
<div class="clear">
<hr/>
@@ -231,7 +231,49 @@
</div>
<div id="bodyColumn">
<div id="contentBox">
- <!-- Licensed to the Apache Software Foundation (ASF) under one --><!-- or more contributor license agreements. See the NOTICE file --><!-- distributed with this work for additional information --><!-- regarding copyright ownership. The ASF licenses this file --><!-- to you 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/referen
ces/apt-format.html --><div class="section"><h2>Introduction to Maven 2.0 Plugin Development<a name="Introduction_to_Maven_2.0_Plugin_Development"></a></h2><p>Maven consists of a core engine which provides basic project-processing capabilities and build-process management, and a host of plugins which are used to execute the actual build tasks.</p><div class="section"><h3>What is a Plugin?<a name="What_is_a_Plugin"></a></h3><p>"Maven" is really just a core framework for a collection of Maven Plugins. In other words, plugins are where much of the real action is performed, plugins are used to: create jar files, create war files, compile code, unit test code, create project documentation, and on and on. Almost any action that you can think of performing on a project is implemented as a Maven plugin.</p><p>Plugins are the central feature of Maven that allow for the reuse of common build logic across multiple projects. They do this by executing an "action" (i.e
. creating a WAR file or compiling unit tests) in the context of a project's description - the Project Object Model (POM). Plugin behavior can be customized through a set of unique parameters which are exposed by a description of each plugin goal (or Mojo).</p><p>One of the simplest plugins in Maven 2.0 is the Clean Plugin. The <a href="../../plugins/maven-clean-plugin/">Maven Clean plugin</a> (maven-clean-plugin) is responsible for removing the target directory of a Maven 2 project. When you run "mvn clean", Maven 2 executes the "clean" goal as defined in the Clean plug-in, and the target directory is removed. The Clean plugin <a href="../../plugins/maven-clean-plugin/clean-mojo.html">defines a parameter</a> which can be used to customize plugin behavior, this parameter is called outputDirectory and it defaults to ${project.build.directory}.</p></div><div class="section"><h3>What is a Mojo (<i>And Why the H--- is it Named 'Mojo'</i>)?<a name="What_is_a_M
ojo_And_Why_the_H---_is_it_Named_Mojo"></a></h3><p>A Mojo is really just a goal in Maven 2, and plug-ins consist of any number of goals (Mojos). Mojos can be defined as annotated Java classes or Beanshell script. A Mojo specifies metadata about a goal: a goal name, which phase of the lifecycle it fits into, and the parameters it is expecting.</p><p>MOJO is a play on POJO (Plain-old-Java-object), substituting "Maven" for "Plain". Mojo is also an iteresting word (see <a class="externalLink" href="http://www.answers.com/mojo&r=67">definition</a>). From <a class="externalLink" href="http://www.wikipedia.org">Wikipedia</a>, a "mojo" is defined as: "...a small bag worn by a person under the clothes (also known as a mojo hand). Such bags were thought to have supernatural powers, such as protecting from evil, bringing good luck, etc."</p></div><div class="section"><h3>What is the Build Lifecycle? (Overview)<a name="What_is_the_Build_Lifecy
cle_Overview"></a></h3><p>The build lifecycle is a series of common stages through which all project builds naturally progress. Plugin goals are bound to specific stages in the lifecycle.</p></div></div><div class="section"><h2>Resources<a name="Resources"></a></h2><ol style="list-style-type: decimal"><li><a href="../plugin/guide-java-plugin-development.html">Plugin development guide</a></li><li><a href="../mini/guide-configuring-plugins.html">Configuring plugins</a></li></ol></div><div class="section"><h2>Comparison to Maven 1.x Plugins<a name="Comparison_to_Maven_1.x_Plugins"></a></h2><div class="section"><h3>Similarities to Maven 1.x<a name="Similarities_to_Maven_1.x"></a></h3><p>Maven 2.0 is similar to its predecessor in that it has two main functions. First, it organizes project data into a coherent whole, and exposes this data for use within the build process. Second, Maven marshals a set of plugins to do the heavy lifting and execute the actual steps of the build.</p>
<p>Many things in Maven 2 will have at least superficial familiarity to users of Maven 1, and the plugin system is no exception. Maven 2 plugins appear to behave much as their 1.x counterparts do. Like 1.x plugins, they use both project information and custom-defined configurations to perform their work. Also, Maven 2 plugins are organized and executed in a coherent way by the build engine itself - that is to say, the engine is still responsible for organizing and fulfilling a plugin's requirements before executing the plugin itself.</p><p>Operationally, Maven 2.0 should feel very much like a more performant big brother of Maven 1.x. While the POM has definitely changed, it has the same basic layout and features (with notable additions). However, this is where the similarity ends. Maven 2.0 is a complete redesign and reimplementation of the Maven build concept. As such, it has a much different and more evolved architecture - at least to our minds. <b>;-)</b></p></div><div cl
ass="section"><h3>Differences from Maven 1.x<a name="Differences_from_Maven_1.x"></a></h3><p>However similar the architectures may seem, Maven 2 offers a much richer environment for its plugins than Maven 1 ever did. The new architecture offers a managed lifecycle, multiple implementation languages, reusability outside of the build system, and many more advantages. Arguably the biggest advantage is the ability to write Maven plugins entirely in Java, which allows developers to tap into a rich landscape of development and testing tools to aid in their efforts.</p><p>Prior to Maven 2.0, the build system organized relevant plugins into a loosely defined lifecycle, which was determined based on goal prerequisites and decoration via preGoals and postGoals. That experience was critical for the Maven community. It taught us that even though there may be a million different build scenarios out there, most of the activities in those builds fit into just a few broad categories. Moreov
er, the category to which a goal fits serves as an accurate predictor for where in the build process the goal should execute. Drawing on this experience, Maven 2.0 defines a lifecycle within which plugins are managed according to their relative position within this lifecycle.</p><p>Starting with Maven 2.0, plugins implemented in different programming or scripting languages can coexist within the same build process. This removes the requirement that plugin developers learn a particular scripting language in order to interact with Maven. It also reduced the risk associated with the stability or richness of any particular scripting language.</p><p>Also starting with Maven 2.0 is an effort to integrate multiproject builds directly into the core architecture. In Maven 1.x, many large projects were fragmented into smaller builds to sidestep issues such as conditional compilation of a subset of classes; separation of client-server code; or cyclical dependencies between distinct app
lication libraries. This in turn created extra complexity with running builds, since multiple builds had to be run in order to build the application as a whole - one or more per project. While the first version (1.x) did indeed address this new multiple projects issue, it did so as an afterthought. The Reactor was created to act as a sort of <i>apply-to-all-these</i> function, and the multiproject plugin was later added to provide Reactor settings for some common build types. However, this solution (it <i>is</i> really only one solution, plus some macros) really never integrated the idea of the multi-project build process into the maven core conceptual framework.</p></div><div class="section"><h3>Why Change the Plugin Architecture?<a name="Why_Change_the_Plugin_Architecture"></a></h3><p>See the previous section for the long version, but the short version can be summed up by the following list of benefits.</p><ul><li>A managed lifecycle</li><li>Multiple implementation languag
es</li><li>Reusability outside of the build system</li><li>The ability to write Maven plugins entirely in Java</li></ul><p>In Maven 1.0, a plugin was defined using Jelly, and while it was possibly to write a plugin in Java, you still had to wrap your plugin with some obligatory Jelly script. An XML-based scripting language which is interpreted at run-time isn't going to be the best choice for performance, and the development team thought it wise to adopt an approach which would allow plugin developers to choose from an array of plugin implementation choices. The first choice in Maven 2 should be Java plugins, but you may also use one of the supported scripting languages like Beanshell.</p><p>To summarize, the development team saw some critical gaps in the API and architecture of Maven 1.0 plug-ins, and the team decided that addressing these deficiencies was critical to the future progress of Maven from a useful tool to something more robust.</p></div></div>
+ <!-- Licensed to the Apache Software Foundation (ASF) under one --><!-- or more contributor license agreements. See the NOTICE file --><!-- distributed with this work for additional information --><!-- regarding copyright ownership. The ASF licenses this file --><!-- to you 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/referen
ces/apt-format.html --><div class="section">
+<h2>Introduction to Maven 2.0 Plugin Development<a name="Introduction_to_Maven_2.0_Plugin_Development"></a></h2>
+<p>Maven consists of a core engine which provides basic project-processing capabilities and build-process management, and a host of plugins which are used to execute the actual build tasks.</p>
+<div class="section">
+<h3>What is a Plugin?<a name="What_is_a_Plugin"></a></h3>
+<p>"Maven" is really just a core framework for a collection of Maven Plugins. In other words, plugins are where much of the real action is performed, plugins are used to: create jar files, create war files, compile code, unit test code, create project documentation, and on and on. Almost any action that you can think of performing on a project is implemented as a Maven plugin.</p>
+<p>Plugins are the central feature of Maven that allow for the reuse of common build logic across multiple projects. They do this by executing an "action" (i.e. creating a WAR file or compiling unit tests) in the context of a project's description - the Project Object Model (POM). Plugin behavior can be customized through a set of unique parameters which are exposed by a description of each plugin goal (or Mojo).</p>
+<p>One of the simplest plugins in Maven 2.0 is the Clean Plugin. The <a href="../../plugins/maven-clean-plugin/">Maven Clean plugin</a> (maven-clean-plugin) is responsible for removing the target directory of a Maven 2 project. When you run "mvn clean", Maven 2 executes the "clean" goal as defined in the Clean plug-in, and the target directory is removed. The Clean plugin <a href="../../plugins/maven-clean-plugin/clean-mojo.html">defines a parameter</a> which can be used to customize plugin behavior, this parameter is called outputDirectory and it defaults to ${project.build.directory}.</p></div>
+<div class="section">
+<h3>What is a Mojo (<i>And Why the H--- is it Named 'Mojo'</i>)?<a name="What_is_a_Mojo_And_Why_the_H---_is_it_Named_Mojo"></a></h3>
+<p>A Mojo is really just a goal in Maven 2, and plug-ins consist of any number of goals (Mojos). Mojos can be defined as annotated Java classes or Beanshell script. A Mojo specifies metadata about a goal: a goal name, which phase of the lifecycle it fits into, and the parameters it is expecting.</p>
+<p>MOJO is a play on POJO (Plain-old-Java-object), substituting "Maven" for "Plain". Mojo is also an iteresting word (see <a class="externalLink" href="http://www.answers.com/mojo&r=67">definition</a>). From <a class="externalLink" href="http://www.wikipedia.org">Wikipedia</a>, a "mojo" is defined as: "...a small bag worn by a person under the clothes (also known as a mojo hand). Such bags were thought to have supernatural powers, such as protecting from evil, bringing good luck, etc."</p></div>
+<div class="section">
+<h3>What is the Build Lifecycle? (Overview)<a name="What_is_the_Build_Lifecycle_Overview"></a></h3>
+<p>The build lifecycle is a series of common stages through which all project builds naturally progress. Plugin goals are bound to specific stages in the lifecycle.</p></div></div>
+<div class="section">
+<h2>Resources<a name="Resources"></a></h2>
+<ol style="list-style-type: decimal">
+<li><a href="../plugin/guide-java-plugin-development.html">Plugin development guide</a></li>
+<li><a href="../mini/guide-configuring-plugins.html">Configuring plugins</a></li></ol></div>
+<div class="section">
+<h2>Comparison to Maven 1.x Plugins<a name="Comparison_to_Maven_1.x_Plugins"></a></h2>
+<div class="section">
+<h3>Similarities to Maven 1.x<a name="Similarities_to_Maven_1.x"></a></h3>
+<p>Maven 2.0 is similar to its predecessor in that it has two main functions. First, it organizes project data into a coherent whole, and exposes this data for use within the build process. Second, Maven marshals a set of plugins to do the heavy lifting and execute the actual steps of the build.</p>
+<p>Many things in Maven 2 will have at least superficial familiarity to users of Maven 1, and the plugin system is no exception. Maven 2 plugins appear to behave much as their 1.x counterparts do. Like 1.x plugins, they use both project information and custom-defined configurations to perform their work. Also, Maven 2 plugins are organized and executed in a coherent way by the build engine itself - that is to say, the engine is still responsible for organizing and fulfilling a plugin's requirements before executing the plugin itself.</p>
+<p>Operationally, Maven 2.0 should feel very much like a more performant big brother of Maven 1.x. While the POM has definitely changed, it has the same basic layout and features (with notable additions). However, this is where the similarity ends. Maven 2.0 is a complete redesign and reimplementation of the Maven build concept. As such, it has a much different and more evolved architecture - at least to our minds. <b>;-)</b></p></div>
+<div class="section">
+<h3>Differences from Maven 1.x<a name="Differences_from_Maven_1.x"></a></h3>
+<p>However similar the architectures may seem, Maven 2 offers a much richer environment for its plugins than Maven 1 ever did. The new architecture offers a managed lifecycle, multiple implementation languages, reusability outside of the build system, and many more advantages. Arguably the biggest advantage is the ability to write Maven plugins entirely in Java, which allows developers to tap into a rich landscape of development and testing tools to aid in their efforts.</p>
+<p>Prior to Maven 2.0, the build system organized relevant plugins into a loosely defined lifecycle, which was determined based on goal prerequisites and decoration via preGoals and postGoals. That experience was critical for the Maven community. It taught us that even though there may be a million different build scenarios out there, most of the activities in those builds fit into just a few broad categories. Moreover, the category to which a goal fits serves as an accurate predictor for where in the build process the goal should execute. Drawing on this experience, Maven 2.0 defines a lifecycle within which plugins are managed according to their relative position within this lifecycle.</p>
+<p>Starting with Maven 2.0, plugins implemented in different programming or scripting languages can coexist within the same build process. This removes the requirement that plugin developers learn a particular scripting language in order to interact with Maven. It also reduced the risk associated with the stability or richness of any particular scripting language.</p>
+<p>Also starting with Maven 2.0 is an effort to integrate multiproject builds directly into the core architecture. In Maven 1.x, many large projects were fragmented into smaller builds to sidestep issues such as conditional compilation of a subset of classes; separation of client-server code; or cyclical dependencies between distinct application libraries. This in turn created extra complexity with running builds, since multiple builds had to be run in order to build the application as a whole - one or more per project. While the first version (1.x) did indeed address this new multiple projects issue, it did so as an afterthought. The Reactor was created to act as a sort of <i>apply-to-all-these</i> function, and the multiproject plugin was later added to provide Reactor settings for some common build types. However, this solution (it <i>is</i> really only one solution, plus some macros) really never integrated the idea of the multi-project build process into the maven core
conceptual framework.</p></div>
+<div class="section">
+<h3>Why Change the Plugin Architecture?<a name="Why_Change_the_Plugin_Architecture"></a></h3>
+<p>See the previous section for the long version, but the short version can be summed up by the following list of benefits.</p>
+<ul>
+<li>A managed lifecycle</li>
+<li>Multiple implementation languages</li>
+<li>Reusability outside of the build system</li>
+<li>The ability to write Maven plugins entirely in Java</li></ul>
+<p>In Maven 1.0, a plugin was defined using Jelly, and while it was possibly to write a plugin in Java, you still had to wrap your plugin with some obligatory Jelly script. An XML-based scripting language which is interpreted at run-time isn't going to be the best choice for performance, and the development team thought it wise to adopt an approach which would allow plugin developers to choose from an array of plugin implementation choices. The first choice in Maven 2 should be Java plugins, but you may also use one of the supported scripting languages like Beanshell.</p>
+<p>To summarize, the development team saw some critical gaps in the API and architecture of Maven 1.0 plug-ins, and the team decided that addressing these deficiencies was critical to the future progress of Maven from a useful tool to something more robust.</p></div></div>
</div>
</div>
<div class="clear">