[jira] [Commented] (MNG-6079) 3.4 regression: cannot override version of a dependencyManagement in a submodule any more

["Curtis Rueden (JIRA)" <ji...@apache.org>]

    [ 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:

		<dependency>
			<groupId>ca.mcgill</groupId>
			<artifactId>Sholl_Analysis</artifactId>
			<scope>runtime</scope>
		</dependency>

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

	<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>

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

	<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>

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 {{<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)