This is an automated email from the ASF dual-hosted git repository.
elharo pushed a commit to branch elharo-patch-2
in repository https://gitbox.apache.org/repos/asf/maven-site.git
commit eb49cde5c3ceaf3acbf9b5c0b68f7d8813491da6
Author: Elliotte Rusty Harold <elh...@users.noreply.github.com>
AuthorDate: Mon Oct 21 23:17:50 2024 +0000
[MNGSITE-393] Remove another Maven 2.x reference
---
content/apt/guides/mini/guide-default-execution-ids.apt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/apt/guides/mini/guide-default-execution-ids.apt
b/content/apt/guides/mini/guide-default-execution-ids.apt
index b354b7fb..3ee8ae1b 100644
--- a/content/apt/guides/mini/guide-default-execution-ids.apt
+++ b/content/apt/guides/mini/guide-default-execution-ids.apt
@@ -54,7 +54,7 @@ Guide to Configuring Default Mojo Executions
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
+ 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
<<<default-cli>>> 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
<<<default-\<goalName\>>>> assigned to it, to allow configuration of each
