[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15419236#comment-15419236
]
Curtis Rueden commented on MNG-5971:
------------------------------------
This change breaks backwards compatibility, and IMHO should be reverted.
h1. REAL-WORLD EXAMPLE
Consider the following project:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml
Amongst many other dependencies, this project has:
{code:xml}
<dependency>
<groupId>ca.mcgill</groupId>
<artifactId>Sholl_Analysis</artifactId>
<scope>runtime</scope>
</dependency>
{code}
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
{code:xml}
<properties>
<!-- Sholl Analysis - https://github.com/tferr/ASA -->
<Sholl_Analysis.version>3.6.2</Sholl_Analysis.version>
</properties>
...
<dependencyManagement>
<dependencies>
<!-- Sholl Analysis - https://github.com/tferr/ASA -->
<dependency>
<groupId>ca.mcgill</groupId>
<artifactId>Sholl_Analysis</artifactId>
<version>${Sholl_Analysis.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
{code}
With Maven 3.3.9, we have:
{code}
$ mvn dependency:list|grep Sholl
[INFO] ca.mcgill:Sholl_Analysis:jar:3.6.2:runtime
{code}
But with Maven 3.4.0-20160806.181437-172, we get:
{code}
$ mvn dependency:list|grep Sholl
[INFO] ca.mcgill:Sholl_Analysis:jar:3.6.1:runtime
{code}
!!!
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
{code:xml}
<dependencyManagement>
<dependencies>
<!-- BigDataViewer BOM -->
<dependency>
<groupId>sc.fiji</groupId>
<artifactId>pom-bigdataviewer</artifactId>
<version>${pom-bigdataviewer.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<!-- TrakEM2 BOM -->
<dependency>
<groupId>sc.fiji</groupId>
<artifactId>pom-trakem2</artifactId>
<version>${pom-trakem2.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
{code}
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
h1. 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. This seems inconsistent.
I understand and appreciate that I am naive of the deepest nuances of the Maven
project model and how it gets synthesized. But:
# The above behavior will break all of my projects.
# 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
previously suggested.
See also this thread on the maven-users list:
*
http://mail-archives.apache.org/mod_mbox/maven-users/201608.mbox/%3CCADN69yn-ffoEV6_Q24VXAcSKbdXrT6CL263ih-LvvEdoYmL4CA%40mail.gmail.com%3E
> Imported dependencies should be available to inheritance processing
> -------------------------------------------------------------------
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
> Affects Versions: 3.3.3
> Reporter: Stephane Nicoll
> Assignee: Christian Schulte
> Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> When a project extends from a parent with a {{dependencyManagement}} section,
> it is not always possible to properly override (and align) the version to use
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure
> their versions are consistent.
> The following project demonstrates the issue:
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with
> version A and we use the same bom with version B in the child. Version B is
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom
> in the parent, we use a direct dependency (provided by that bom). We still
> use the bom with a different version. In that case all the dependencies but
> the one provided by the parent are overridden (leading to mixed versions for
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the
> graph of dependencies should be flatten at each step for a proper override.
> Thoughts? Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
