maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schulte ...@schulte.it>
Subject Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)
Date Fri, 12 Aug 2016 17:46:40 GMT
Am 12.08.2016 um 19:16 schrieb Curtis Rueden:
> Hi all,
>
> Concerned by this thread, I did some tests. And I have to say, the new
> Maven 3.4.0 dependency resolution rules seem like a step backwards.
>
> == 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.

That's exactly the issue we have solved. The dependency management at 
child level did not override the parent but it should as everything else 
does.

> - IMHO, it violates the Principle of Least Astonishment.

No. It's the opposite. You would expect a child dependency management to 
override the parent and not the other way around.

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

That's become easier now as you can override things at child level you 
could not have overriden before.

> - It is now not possible to override version properties _in the POM itself_
> to trump the dependencyManagement versions.

That's correct. That's why I wanted to not change the import scope and 
introduce a new scope called include.

>
> But strangely, you _can_ still override the version property on the CLI via
> -DSholl_Analysis.version=x.y.z.

Because that CLI property will override it the parent as well.

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

Simply by applying inheritance. This is what MNG-5971 is about. Imported 
dependencies have not been part of inheritance processing prior 3.4 but 
should. Think about the import scope as a way to just include some 
dependencies in the dependency management where it is used.

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

It will also fix builds. You could just update your poms to make use of 
inheritance. You would just need to declare the dependency in question 
in the dependency management of the inheritance level in question.

Regards,
-- 
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message