Allow mavenBom to override dependency #173
Comments
|
Thanks for the detailed report, @rwinch. I will confess that, up until now, I've only given thought to the relative ordering of multiple boms and hadn't considered the effect that the relative ordering of a bom and an individual managed dependency should have. In short, the current behaviour isn't the way it is for any well-considered reason. That said, changing it does bring the risk of breaking someone's build so it's probably not appropriate for a 1.0.x release. #165 is also somewhat related to this as it proposes making the behaviour described above configurable, e.g. last wins, first wins, etc. |
|
Thanks for the fast reply @wilkinsona. I do want to ensure I point out that the way it currently behaves aligns with Maven. I'm guessing this is due to the Maven philosophy of deeper dependencies have less precedence than those explicitly listed. It just so happens that this is inconvenient for a number of scenarios, so I would like to be able to override with the BOM. |
That isn't the case for when two boms are imported. In Maven the first import will win, whereas in this plugin (and as you have observed above) the last bom will win. That difference also wasn't intentional, but it seems to be the most intuitive and hasn't caused any problems thus far. A decision was made a while ago to stick with it. Aligning the behaviour of a single managed dependency and a bom to be last-wins makes sense to me, irrespective of what Maven does. |
Sorry. I should have been more clear. If you have a dependency management section with a dependency and then a bom in Maven, the dependency wins. I believe this is due to the Maven philosophy of deeper dependencies have less precedence. For example: <?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<groupId>foo</groupId>
<artifactId>bar</artifactId>
<version>1.0.0.BUILD-SNAPSHOT</version>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>4.2.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-framework-bom</artifactId>
<version>4.3.0.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<scope>compile</scope>
</dependency>
</dependencies>
</project>$ mvn dependency:list
...
[INFO] The following files have been resolved:
[INFO] commons-logging:commons-logging:jar:1.2:compile
[INFO] org.springframework:spring-core:jar:4.2.0.RELEASE:compile
This works well for me (this is what I would like it to do anyways), but wanted to be sure I communicated Maven's current behavior. Thanks again! |
|
@wilkinsona Would you consider adding a flag to support allowing a bom to override the properties in 1.x? |
|
I'll certainly consider it, although I'm rather wary of how complex it may get. There's a somewhat similar requirement in #160. After refreshing my memory, the current behaviour is a side-effect of wanting a version declared on a dependency to take precedence over any dependency management for that dependency (e1bb745). To implement what's being requested here, things would have to be further differentiated so that dependency management from a bom, dependency management for a single dependency, and implicit dependency management that comes from a dependency declared with a version were all tracked and considered separately. |
|
It might be obvious, but I wanted to point out that this behavior prevents the spring-io-plugin from working correctly. When a project manages a dependency explicitly for its standard build, then the spring-io-plugin does not override the version. If one is careful they can have conditional logic to disable the dependency management for dependencies in the Spring IO platform. However, this is somewhat fragile because you must keep track of which dependencies are in the Spring IO Platform and might not even know which version of the Spring IO Platform is going to be tested. |
That's not my experience. REST Docs uses the dependency management plugin, and the Spring IO plugin manages to override the dependency management to use its versions. I have the "normal" dependency management configured like this: And the Platform's configured like this: The end result is that the Platform's versions win. Here's the versions with Cairo-BUILD-SNAPSHOT: |
|
@wilkinsona Thanks for the reply. My mistake on this. It appears that this does not cause issues with spring-io-plugin. Sorry for the misinformation. I'm not sure what I was doing wrong previously. |
|
same issue I believe I have my own BOM generated, it's overriding assertj-core and a couple of other things, just by setting their property version https://bitbucket.org/xenworks/util/src/f6aa3210c8c06f1d23aafcb7980edcb10d9517b3/build.gradle howver it's not using v2.8 here's the generated pom, in case I've made a mistake somewhere my test compile deps |
|
@xenoterracide Your bom doesn't appear to use the |
|
right, but shouldn't the properties I set in my bom affect the versions set in brussels maybe maven doesn't work that way either, originally I did have my bom extend platform bom, I'm still working out the best way to dedupe my migration. |
|
Properties in a bom are isolated to that bom and its ancestors |
|
i have the same problem, could i deal with it ? |
|
Maybe can help https://docs.spring.io/dependency-management-plugin/docs/current/reference/html/ look for "Overriding the Dependency Management" |
I realize this is inconsistent with Maven, but I'd love for the
io.spring.dependency-managementto support overriding adependencydeclaration with amavenBom. To illustrate:Two mavenBom
Currently if there are two
mavenBoms the second one wins (this is how I would expect it to work). For example:plugins { id 'java' id 'io.spring.dependency-management' version '1.0.2.RELEASE' } dependencyManagement { imports { mavenBom 'org.springframework:spring-framework-bom:4.2.0.RELEASE' mavenBom 'org.springframework:spring-framework-bom:4.3.0.RELEASE' } } repositories { mavenCentral() } dependencies { compile 'org.springframework:spring-core' }mavenBom then dependency
If a
mavenBomis followed by adependency, thedependencywins (this is how I would expect it to win). For example:plugins { id 'java' id 'io.spring.dependency-management' version '1.0.2.RELEASE' } dependencyManagement { imports { mavenBom 'org.springframework:spring-framework-bom:4.2.0.RELEASE' } dependencies { dependency 'org.springframework:spring-core:4.3.0.RELEASE' } } repositories { mavenCentral() } dependencies { compile 'org.springframework:spring-core' }dependency followed by mavenBom
If a
dependencyis followed by amavenBomthedependencywins.plugins { id 'java' id 'io.spring.dependency-management' version '1.0.2.RELEASE' } dependencyManagement { dependencies { dependency 'org.springframework:spring-core:4.3.0.RELEASE' } imports { mavenBom 'org.springframework:spring-framework-bom:4.2.0.RELEASE' } } repositories { mavenCentral() } dependencies { compile 'org.springframework:spring-core' }This is how maven behaves, but to me is quite inconvenient because I would like to override an explicit
dependencywith amavenBomIt would be nice if thedependencycould be overridden by themavenBom.The text was updated successfully, but these errors were encountered: