[
https://issues.apache.org/jira/browse/MNG-6079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15419191#comment-15419191
]
Curtis Rueden edited comment on MNG-6079 at 8/12/16 5:46 PM:
-------------------------------------------------------------
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
like suggested.
was (Author: ctrueden):
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:shell}
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:shell}
$ 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
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 {{<dependencyManagement>}} section from another pom, you
> can use a property for the version:
> {code}
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>org.apache.maven.surefire</groupId>
> <artifactId>surefire</artifactId>
> <version>${surefire.version}</version>
> <type>pom</type>
> <scope>import</scope>
> </dependency>
> </dependencies>
> </dependencyManagement>
> {code}
> In Maven 3.3 and before, that version could be overridden in submodules, by
> overriding the property.
> In Maven 3.4, this doesn't work any more: redefining the property doesn't
> change the dependencies which are defined.
> I attach a simple example that uses surefire dependencies.
> {{mvn dependency:list}} will yield different results:
> * surefire-api:jar:2.12 with Maven 3.3, because this is the overridden
> version in the pom
> * surefire-api:jar:2.10 with Maven 3.4 (as of snapshot 2016-08-06), which is
> the version defined in the parent pom
> It is admittedly a corner case, or potentially a bug fix. In Maven 3.4, the
> behaviour of <dependencyManagement> is now more consistent with the one of
> <dependencies>, where you can't redefine a dependency version simply by
> overriding a property.
> It is however a change in behaviour -- which broke my build.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
