THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
In Maven 2.x we have a boolean mojo annotation @aggregator with the following effects on the mojo execution:
Execution | For mojos executed directly from the CLI, the mojo will only be executed once and not per each project in the reactor. |
Dependency Resolution | If an aggregating mojo is annotated with |
Forking | The annotation |
Besides, aggregating mojos often use the parameter expression reactorProjects or MavenSession.getSortedProjects() to get hold off all the projects in the reactor for processing.
...
It's assumed that build hooks are implemented as regular mojos (with special annotations) and are introduced to a build via plugin executions defined in the POM. However, the <phase> element of such a plugin execution would have a slightly different meaning. Instead of saying "bind this mojo into lifecycle phase xyz" it should be intepreted interpreted as "if the build executes to phase xyz or beyond, register this mojo as a pre-/post-build hook".
...
To address this distinction in aggregation scope, we might start off with new mojo annotations like @aggregator top-level|project that plugin authors can use to indicate the desired operational mode. But it seems this ultimatively ultimately demands a new POM element to enable the user to choose the mode that fits his intentions.
...
The details of this are left open for future design. Right now, I simply assume we will introduce new mojo annotations to mark those goals and distinguish them from the summary mojos that continue to use the existing @aggregator annoation annotation.