[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing

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

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