svn commit: r1921535 - /maven/website/content/guides/mini/guide-default-execution-ids.html

[sv...@apache.org]

Author: svn-site-role
Date: Thu Oct 24 20:39:56 2024
New Revision: 1921535

Log:
Site checkin for project Apache Maven Site

Modified:
    maven/website/content/guides/mini/guide-default-execution-ids.html

Modified: maven/website/content/guides/mini/guide-default-execution-ids.html
==============================================================================
--- maven/website/content/guides/mini/guide-default-execution-ids.html (original)
+++ maven/website/content/guides/mini/guide-default-execution-ids.html Thu Oct 24 20:39:56 2024
@@ -157,7 +157,7 @@
 <li>Mojo executions that are bound to the lifecycle as part of the default mapping for a particular packaging, especially in cases where the same mojos need to be added to a second execution with different configuration.</li>
 <li>Groups of mojos from the same plugin that are bound to the lifecycle as part of the default mapping for a particular packaging, but require separate configurations.</li></ul><section>
 <h2>Default <code>executionId</code>s for Implied Executions</h2>
-<p>When you consider the fact that the aforementioned configuration use cases are for mojos that are not explicitly mentioned in the POM, it's reasonable to refer to them as implied executions. But if they're implied, how can Maven allow users to provide configuration for them? The solution we've implemented is rather simple and low-tech, but should be more than adequate to handle even advanced use cases. Starting in Maven 2.2.0, each mojo invoked directly from the command line will have an execution Id of <code>default-cli</code> assigned to it, which will allow the configuration of that execution from the POM by using this default execution Id. Likewise, each mojo bound to the build lifecycle via the default lifecycle mapping for the specified POM packaging will have an execution Id of <code>default-&lt;goalName&gt;</code> assigned to it, to allow configuration of each default mojo execution independently.</p><section>
+<p>When you consider the fact that the aforementioned configuration use cases are for mojos that are not explicitly mentioned in the POM, it's reasonable to refer to them as implied executions. But if they're implied, how can Maven allow users to provide configuration for them? The solution we've implemented is rather simple and low-tech, but should be more than adequate to handle even advanced use cases. Each mojo invoked directly from the command line will have an execution Id of <code>default-cli</code> assigned to it, which will allow the configuration of that execution from the POM by using this default execution Id. Likewise, each mojo bound to the build lifecycle via the default lifecycle mapping for the specified POM packaging will have an execution Id of <code>default-&lt;goalName&gt;</code> assigned to it, to allow configuration of each default mojo execution independently.</p><section>
 <h3>Example: Command-line variant invocation of the assembly plugin</h3>
 <p>Consider the case where the user wants to execute the <code>assembly:assembly</code> mojo directly on the command line, but already has a configuration for the <code>assembly:single</code> mojo that runs during the main build lifecycle. Since these configurations require different options, the user cannot use the plugin-level configuration section to specify common elements.</p>
 <p>In this case, the assembly-plugin configuration might look like this:</p>