> > 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.
So in essence we are relying on the resolution of this artifact (the parent) from the reactor and not from the local repo? The only potential downside is if people rely on this project doing or producing something consumed by the children. > >> 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
