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 <relativePath>
or from the repos. Under the assumption that <relativePath> 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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
