Stephen Connolly wrote:
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 demands a new POM element to enable the user to choose the mode
that fits his intentions.
we could hijack new phases....
pre-reactor-build
pre-module-build
post-module-build
post-reactor-build
The question of to what set of projects an aggregating mojo applies
arises for both the hook mojos as well as the summary mojos. The summary
mojos are specially meant to be bound to existing lifecycle phases like
"package" or "site". And even for the hook mojos I envisioned that the
phase declared in the POM should match one of the existing phases,
namely to request that a hook mojo gets only enabled/registered for
execution if the project gets built to the specified lifecycle phase or
beyond.
An example I had in mind was using a post-build hook mojo to tear down
some complex test setup like a server. It doesn't make much sense to run
this mojo if the server gets only started in the "pre-integration-test"
phase but the user invoked just "mvn validate". Hence I assume our
post-build hook mojo would be associated to the "pre-integration-test"
phase as well, telling Maven "if this phase got executed, run me, too".
The new phases would only allow to tell where in the lifecycle a mojo
should principally be executed, not if it should be executed in the
first place.
Forking
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.
+1, but this still won't completely solve the... let's run surefire
again, just to be sure to be sure that the tests pass... of doom that
can occur with aggregator mojos bound to the lifecycle. e.g. it could
be a change from O(n^3) to O((log n) * n^2)
It might also not fully solve the issue you're pointing at but let me
hint at another yet to write proposal where something like
@requiresLifecyclePhase test
should be discussed as well. While there are valid use cases for plugins
to actually fork and grab results from a lifecycle with overlaid plugin
configuration, the case of something like the source:jar mojo is not
properly supported by the core. But as said, that's a story for another
day...
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.
An alternative mechanism is to add empty methods to AbstractMojo which
are invoked pre-reactor, pre-module, post-module and post-reactor...
The problem I see here is that the core can't tell whether these methods
are just empty or actually doing something. But for the sake of
performance, we definitively don't want to make useless calls into
mojos, considering the processing time for calculating and injecting
configuration, setting up class loaders and so on. And also, I don't
think that reflection or bytecode analysis should be employed here to
check the hook methods for contents. A quick glance at the mojo
descriptor should be sufficient to tell how a mojo is supposed to
interact with the lifecycle.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
