You are viewing a plain text version of this content. The canonical link for it is here.
Posted to site-commits@maven.apache.org by sv...@apache.org on 2022/05/28 21:17:28 UTC

svn commit: r1901373 - in /maven/website/content: apache-maven.pdf guides/mini/guide-configuring-plugins.html maven-site-1.0-site.jar

Author: svn-site-role
Date: Sat May 28 21:17:27 2022
New Revision: 1901373

Log:
Site checkin for project Apache Maven Site

Modified:
    maven/website/content/apache-maven.pdf
    maven/website/content/guides/mini/guide-configuring-plugins.html
    maven/website/content/maven-site-1.0-site.jar

Modified: maven/website/content/apache-maven.pdf
==============================================================================
Binary files - no diff available.

Modified: maven/website/content/guides/mini/guide-configuring-plugins.html
==============================================================================
--- maven/website/content/guides/mini/guide-configuring-plugins.html (original)
+++ maven/website/content/guides/mini/guide-configuring-plugins.html Sat May 28 21:17:27 2022
@@ -184,9 +184,7 @@ Vincent Siveton" />
 <p><b>Important Note</b>: Always define the version of each plugin used to guarantee build reproducibility. A good practice is to specify each build plugin's version in a <code>&lt;build&gt;&lt;pluginManagement/&gt;&lt;/build&gt;</code> element. Often the &lt;pluginManagement/&gt; element is found in the parent POM. For reporting plugins, specify each version in the <code>&lt;reporting&gt;&lt;plugins/&gt;&lt;/reporting&gt;</code> element (and in the <code>&lt;build&gt;&lt;pluginManagement/&gt;&lt;/build&gt;</code> element too).</p></section><section>
 <h3><a name="Generic_Configuration">Generic Configuration</a></h3>
 <p>Maven plugins (build and reporting) are configured by specifying a <code>&lt;configuration&gt;</code> element where the child elements of the <code>&lt;configuration&gt;</code> 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.) Say, for example, you have a Mojo that performs a query against a particular URL, with a specified timeout and list of options. The Mojo might look like the following:</p>
-<div class="source"><pre class="prettyprint linenums">/**
- * @goal query
- */
+<div class="source"><pre class="prettyprint linenums">@Mojo( name = &quot;query&quot; )
 public class MyQueryMojo
     extends AbstractMojo
 {
@@ -437,10 +435,7 @@ public class MyQueryMojo
 &lt;/project&gt;</pre></div>
 <p>If there are multiple executions bound to different phases, then the mojo is executed once for each phase indicated. Meaning, <code>execution1</code> will be executed applying the configuration setup when the phase of the build is test, and <code>execution2</code> will be executed applying the configuration setup when the build phase is already in install.</p>
 <p>Now, let us have another mojo example which shows a default lifecycle phase binding.</p>
-<div class="source"><pre class="prettyprint linenums">/**
- * @goal query
- * @phase package
- */
+<div class="source"><pre class="prettyprint linenums">@Mojo( name = &quot;query&quot;, defaultPhase = LifecyclePhase.PACKAGE )
 public class MyBoundQueryMojo
     extends AbstractMojo
 {

Modified: maven/website/content/maven-site-1.0-site.jar
==============================================================================
Binary files - no diff available.