Brian Fox wrote:
Project Ordering
A project with packaging pom can serve both as a parent POM and as an
aggregator POM. [...] For this reason, the project sorter needs to
be changed to mark an aggregator POM as a dependant of all its
modules.
What happens in the normal case where the pom is both inherited and an
aggregator?
Such a project would be built after its child modules. Basically, the
occurrence of <parent> in a POM should no longer establish any kind of
dependency between the parent project and the inheriting project, only
aggregation would do so.
I wonder if a phase that means "after all my children"
would be better, then you would have current behavior, but you could
use this phase for example to bind an assembly mojo.
This seems to resemble the "summarize" phase from [0], right? My
understanding of this idea is that it would result in an execution like:
Aggregator
Child
1. Aggregator
a) validate
b) (...)
c) deploy
2. Child
a) validate
b) (...)
c) deploy
3. Aggregator
a) summarize
Note that this "summarize" phase executes completely outside of the
regular project lifecycle. In particular, it executes after all other
lifecycle phases of the aggregator project. So whatever an assembly mojo
attached to the "summarize" phase produces, it would not be
visible/consumable by the project's "install" or "deploy" phase, for
instance.
That's why I figured we need to distinguish pre-/post-build hooks from
summary mojos, the latter being meant to run after all child modules but
within the aggregator project's lifecycle.
The other problem I see with the "summarize" phase is: Given a POM that
binds a mojo to this phase, should the mojo be run if the user invokes
only "mvn validate" or does is it meant to only come to live if we run a
later phase like "mvn package"? I mean, how would one define the
prerequisite phase that needs to be run before the "summarize" phase
should be enabled?
Not entirely related to aggregation, but in the same vein: I think an
annotation for the @execute phase is needed to indicate "fork to this
phase only if it won't be run otherwise, else bind to the phase when
it gets there".
Agreed, I think that's the same issue I mentioned in my answer to
Stephens first feedback, look out for @requiresLifecyclePhase. To fork
or not to fork is something I would like to discuss separately. Tn the
context of aggregation, the question is just what set of projects to
fork (if at all).
Benjamin
[0] http://docs.codehaus.org/display/MAVEN/Atypical+Plugin+Use+Cases
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
