THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
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 as "if the build executes to phase xyz or beyond, register this mojo as a pre-/post-build hook".
A further mojo annotation could be introduced to enable the plugin author to control whether a post-build hook should be called regardless whether the build failed before, i.e. to provide some finally-like cleanup.
An example use for a pre-build hook could be an Enforcer rule that checks the build environment before any of the projects start to build.
...
Compared to Maven 2.x, the first style of aggregation resembles somehow the current behavior, i.e. the aggregating mojo being executed in each project it is encountered. The major difference however is the order in which the individual projects are executed. For the common setup where the aggregator POM is also used as parent POM, it would be build ahead of the child modules in 2.x, making aggregation of child output impossible right now.
Also note that the second style of aggregation does not necessarily mean the aggregating mojo is only executed once per reactor build. Consider this variation of the above example where the aggregating mojo is only declared in S1:
...
When running Maven on the top-level project, it seems unintuitive to not say wrong to invoke the aggregating mojo on the entire reactor just because the user ran the build from a higher level of the project hierarchy where however the aggregating mojo is not declared. This would erroneously extend the effect of the aggregator to modules that are no sub modules of its declaring project S1. This is exactly one of the problems we have in Maven 2.x where an aggregating mojo bound to a lifecycle phase causes dependency resolution for the entire reactor although some modules haven't been built yet.
...
A project with packaging pom can serve both as a parent POM and as an aggregator POM. Inheritance belongs to the construction of the effective model and happens long before we reach the lifecycle executor and as such does not care about project order. Aggregation in the sense of a summary mojo however imposes a constraint on the order namely that the project with the aggregating mojo needs to be built after its child modules. For this reason, the project sorter needs to be changed to mark an aggregator POM as a dependant of all its modules. This is contrary to the related article (1) and the current behavior of Maven 2.x. The hopefully few cases where users setup an aggregator POM to produce some artifact for comsumption by sub modules would demand to restructure the build and move the production of the artifact to a sub module of the aggregator.
...
A mojo flagged as @aggregator should no longer trigger dependency resolution for the entire reactor but only for the sub tree of the project hierarchy where the aggregating mojo is rooted. For a mojo invoked directly from the CLI, this effectively makes no differences compared to Maven 2.x. For mojos bound to the lifecycle, this prevents dependency resolution errors on module modules that by due to the project order can never be build in time for the aggregating mojo.
...
Just as with dependency resolution, an aggregating mojo should no longer fork the entire reactor but only the sub tree of the project hierarchy it is relevant for.
Project Retrieval
What remains unclear to myself is how to handle the reactorProjects parameter expression in aggregating mojos. I am tempted to believe that those mojos don't really want all reactor projects but again only the sub tree of the project hierarchy they operate in. If this assumption proves sensible, it would fit the bill to change the semantics of the reactorProjects expression to only deliver the projects from the sub tree of the project hierarchy, thereby being in sync with the changes for dependency resolution and forking.
The obvious alternative is to leave reactorProjects as is and introduce a new expression subProjects or similar that only delivers the current project and all its (transitive) sub modules.
Project Hierarchy Tree
Internally, the core will need to keep the tree of projects that forms the project hierarchy as determined by aggregation, i.e. via the <modules> section in the POM.
Pre-/Post Build Hooks
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.TODO: reactorProjects vs subProjects