+1 for implementing such a functionality in maven-3 Currently things like javadoc:aggregate are basically broken, since one cannot release a project with an aggregated JavaDoc in the parent-pom. (Would have to split parent pom and build-pom for this.)
Also we should imho create a Jira so we don't forget about it ;) LieGrue, strub ----- Original Message ---- > From: Benjamin Bentmann <[email protected]> > To: Maven Developers List <[email protected]> > Sent: Sat, August 15, 2009 2:05:05 PM > Subject: Re: [DISCUSS] Aggregator Plugins > > Brian Fox wrote: > > >> Such a project would be built after its child modules. > > > > So in essence we are relying on the resolution of this artifact (the > > parent) from the reactor and not from the local repo? > > Just to make sure we have the same understanding of "artifact" here. For some > project, we have its POM file itself and zero or more archives, produced > during > the build, that get installed/deployed to the repos. The POM file is > potentially > required by other projects for > a) inheritance > b) import/mixin > c) dependency/metadata collection > > For inheritance, the POM file is either picked from the or from > the repos. Under the assumption that is properly set, something > we want to promote I believe, this logic is independent from the build order. > > For importing and metadata retrieval, the POM file is picked from the pool of > MavenProject instances in the reactor or from the repos. This is also > independent from the build order. > > So to summarize, all requests to resolve the aggregator/parent POM can be > satisfied, regardless of the build order we decide upon. The only artifacts > that > would be affected by building aggregator projects after their child modules > would be those archives that get produced by the aggregator POM, i.e. the > case > you pointed out below. > > > The only > > potential downside is if people rely on this project doing or > > producing something consumed by the children. > > Yes, those builds would need to be restructed by moving the production of > this > something into a child module of the aggregator POM. > > Given that we all seem to agree upon that aggregation in 2.x is not what we > would like to have, I wasn't eager to simply reproduce a buggy concept 1:1 in > 3.x just for the sake of deprecating it. Instead, I was trying to sketch a > vision of what it should be like and how the existing aggregator plugins > could > fit into it such that we can reuse as many of them as possible. For instance, > I > think the proposal solves MASSEMBLY-94 without the need to update the > Assembly > Plugin. > > > Benjamin > > --------------------------------------------------------------------- > 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]
