[
https://jira.codehaus.org/browse/MNG-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338796#comment-338796
]
Jörg Schaible commented on MNG-5207:
------------------------------------
Actually, I don't want to replace any version in the reactor. I just want the
reactor to build all projects in proper sequence, but the reactor of M3 cannot
calculate it.
In the example I have 3 projects Application (A), Delegate (B), and EJB (C).
Those projects are independently released the pom.xml (X) in the parent is not
the parent of the projects, its just there to build all of them together.
However, those projects have dependencies on each other, but not necessarily on
the SNAPSHOTs. Here we have the following situation:
A-1.0-SNAPSHOT depends on B-1.0
B-1.0 depends on C-1.0-classifier
However, A inherits a dependencyManagement section where the version of C is
set to 2.0-SNAPSHOT. Therefore will Maven's dependency resolution correctly
resolve to:
A-1.0-SNAPSHOT depends on B-1.0 depends on C-2.0-SNAPSHOT-classifier
(overwritten)
X declares now its modules to be A,B,C (in exactly this sequence). By default
Maven's reactor will process them simply in "natural" declaration order.
However, M2 detects that C has to be built before A, M3 does not. Note, that M3
only fails if the transitive dependency in the reactor uses a classifier, it
builds in correct sequence for transitive main artifacts.
If A is a project that collects it dependencies (WAR, EAR or using assembly or
dependency plugin), your build will simply fail, if the referenced SNAPSHOT of
C-2.0-classifier is not in your local repository. In worst case, you already
have an old SNAPSHOT there from a previous build and then you get a stale
version.
Real world scenario: We use very fine granular Maven projects with individual
release cycles. There are more than 100 Maven artifacts building together a
product. For simplicity let's claim we produce a final EAR that somehow
incorporates anything else. If we start a new development cycle, we ensure that
all of them use a new major version for the current SNAPSHOT and will depend on
each other (e.g. 3.0.0-SNAPSHOT). We can start major refactorings and do not
have to take care about API stability. M3 is also happy, it calculates always
the proper build sequence.
At some stage we release all of them individually as 3.0.0 and create a 3.0.x
branch for the whole tree. However, since all projects depend on release
versions, the build sequence for the new 3.0.1-SNAPSHOTs is moot, the results
are more or less the same as for the 3.0.0 releases.
Now, we have to incorporate a fix for a trivial bug (e.g. forgotten null check)
into the code base of a basic Maven project (Z). Half of the projects in the
tree depend either directly or indirectly on it. You have to ensure now, that
the 3.0.1-SNAPSHOT of the fixed artifact is incorporated in the project of the
final EAR. All other projects will not be affected even if they depend directly
or indirectly on Z, because compilation will not produce something different
and we have a strict policy for API stability now. In consequence we only have
to modify the pom.xml of the EAR to ensure that it references the new SNAPSHOT
(using a dependencyManagement section), but nothing else. The only requirement
is now, that a build of the tree will at least build Z before EAR (*). The EAR
will then contain all artifacts of the 3.0.0 release, except the 3.0.1-SNAPSHOT
of Z. If everyone is happy after the tests, we can simply release Z-3.0.1 and
EAR-3.0.1 at any time.
*) If the "natural" build order in M3 builds EAR before Z then your build
either fails (e.g. after cleaning the local repo) or someone will test EAR
although the SNAPSHOT of Z it contains, does not yet contain the fix (and at
this stage it gets expensive, because the problem is simply not obvious).
> [Regression] Maven 3 fails to calculate proper build order
> ----------------------------------------------------------
>
> Key: MNG-5207
> URL: https://jira.codehaus.org/browse/MNG-5207
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Reactor and workspace
> Affects Versions: 3.0.3
> Reporter: Jörg Schaible
> Assignee: Kristian Rosenvold
> Priority: Critical
> Fix For: 3.2
>
> Attachments: mng5207-it.tgz, MNG-5207.tgz
>
>
> Maven 3.0.3 and 3.0.4 RC1 fails to build the projects of the reactor in
> proper order, if a transitive dependency (that is part of the reactor build)
> is overruled in the dependencyManagement section with the current SNAPSHOT
> version. Build order is perfectly calculated with Maven 2.2.1.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
