[
https://issues.apache.org/jira/browse/MNG-6079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15419191#comment-15419191
]
Curtis Rueden commented on MNG-6079:
This change breaks backwards compatibility, and IMHO should be reverted.
== REAL-WORLD EXAMPLE ==
Consider the following project:
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml
Amongst many other dependencies, this project has:
ca.mcgill
Sholl_Analysis
runtime
This is defined in the parent sc.fiji:pom-fiji:24.1.0 here:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L830-L835
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L255-L256
3.6.2
...
ca.mcgill
Sholl_Analysis
${Sholl_Analysis.version}
With Maven 3.3.9, we have:
$ mvn dependency:list|grep Sholl
[INFO]ca.mcgill:Sholl_Analysis:jar:3.6.2:runtime
But with Maven 3.4.0-20160806.181437-172, we get:
$ mvn dependency:list|grep Sholl
[INFO]ca.mcgill:Sholl_Analysis:jar:3.6.1:runtime
!!!
I believe this surprising behavior is caused by the fact that the toplevel fiji
POM needs to also include other BOMs via import scope:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml#L49-L68
sc.fiji
pom-bigdataviewer
${pom-bigdataviewer.version}
pom
import
sc.fiji
pom-trakem2
${pom-trakem2.version}
pom
import
The version of pom-bigdataviewer is 3.2.0:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L135-L136
Which extends pom-fiji version 22.3.0 instead of 24.1.0:
*
https://github.com/bigdataviewer/pom-bigdataviewer/blob/pom-bigdataviewer-3.2.0/pom.xml#L5-L9
And that version of pom-fiji defines Sholl_Analysis at 3.6.1 instead:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-22.3.0/pom.xml#L261-L262
== GIST OF THE PROBLEM ==
So, with Maven 3.4.0, dependency management brought in from import scope is now
trumping that brought in from the parent POM itself. This is problematic
because:
- IMHO, it violates the Principle of Least Astonishment.
- It is now more complicated to compose together multiple "subtrees" of
components into a final application which needs to inherit multiple BOMs from
these subtrees.
- It is now not possible to override version properties _in the POM itself_ to
trump the dependencyManagement versions.
But strangely, you _can_ still override the version property on the CLI via
-DSholl_Analysis.version=x.y.z.
I understand and appreciate that I am naive of the deepest nuances of the Maven
project model and how it gets synthesized. But:
1) The above behavior will break all of my projects.
2) I do not know how to restructure my components for Maven 3.4.0 to avoid this
problem.
My vote would be to revert to the old behavior, which seems better to me.
However, if this behavior really must be changed, I would suggest pushing it
till Maven 4, since it will surely break a lot of existing builds.
If this change really goes through, then all previous releases of all of my
projects will no longer build reproducibly with Maven 3.4.0+, since they will
produce different dependency graphs.
Rather than breaking backwards compatibility of import scope by default,
perhaps there could be a setting, or a different scope as Christian Schulte
like suggested.
> 3.4 regression: cannot override version of a dependencyManagement in a
> submodule any more
> -
>
> Key: MNG-6079
> URL: https://issues.apache.org/jira/browse/MNG-6079
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.4.0
>Reporter: Samuel Langlois
>Assignee: Christian Schulte
> Attachments: parent-pom.xml, pom.xml
>
>
> When you import a {{}} section from another pom, you
> can use a property for the version:
> {code}
>
>
>
> org.apache.maven.surefire
>