Hi Christian, Thank you very much for looking at my example, and your speedy reply.
> Can you please add your objections to MNG-5971 in JIRA. Done. I also added the same comments to MNG-6079, which I believe is a legitimate regression caused by the fixing of MNG-5971. > > 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. ... > 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. So if I understand correctly: with the new approach, it is no longer possible to override the version of a transitive dependency, without adding it as a direct dependency of the current project, even though it actually isn't? Or is there still a way? I would like to draw your attention to another use case my community has. Check out this profile: * https://github.com/fiji/pom-fiji/blob/pom-fiji-24.3.0/pom.xml#L1064-L1214 It overrides all managed version properties in the BOM to LATEST, to make snapshot coupling in IDEs (particularly Eclipse) less painful. My understanding of the MNG-5971 change is that the above hack will no longer work. And I cannot see any new way to achieve something similar? How do other projects achieve temporary snapshot couplings during development, without requiring changes to the local dev environment? Yet another wrinkle which occurs to me: What about cases where the version property is used in some configuration somewhere, _besides_ in the dependency declaration? For example, consider the following configuration block: <plugin> <artifactId>maven-jar-plugin</artifactId> <version>3.0.2</version> <configuration> <archive> <manifestEntries> <!-- Add SciJava Common version to the JAR manifest. --> <SciJava-Common-Version>${scijava-common.version}</SciJava-Common-Version> </manifestEntries> </archive> </configuration> </plugin> Of course, the above example is a little contrived, but surely there are real builds in the wild where a dependency version is fed to a plugin configuration somewhere? Won't these versions now be "wrong" from the perspective of the human -- not matching what is actually in the dependency tree? > It will also fix builds. My main beef is the breakage of backwards compatibility. All my old builds which used to work will no longer work. Wouldn't it be better to have some new configuration to achieve the desired result for previously broken builds? Maven component releases are immutable -- I can't go back and fix all my old releases to work with Maven 3.4.0, ever. Thanks, Curtis -- Curtis Rueden LOCI software architect - http://loci.wisc.edu/software ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden Did you know ImageJ has a forum? http://forum.imagej.net/ On Fri, Aug 12, 2016 at 12:46 PM, Christian Schulte <c...@schulte.it> wrote: > 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/ced9faee1c4fba9997a3d61475 >> 9fb6e78e359d4f/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/ced9faee1c4fba9997a3d61475 >> 9fb6e78e359d4f/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-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
