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-<goalName></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-<goalName></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>
