Can't manage version in case of dependency with range

[Godin]

build.gradle to reproduce:

buildscript {
  repositories {
    maven {
      url 'https://plugins.gradle.org/m2/'
    }
  }
  dependencies {
    classpath 'io.spring.gradle:dependency-management-plugin:1.0.0.RELEASE'
  }
}

apply plugin: 'java'
apply plugin: 'io.spring.dependency-management'

repositories {
  mavenCentral()
}

dependencyManagement {
  dependencies {
    dependency 'org.assertj:assertj-core:3.4.1'
    dependency 'org.assertj:assertj-guava:3.0.0'
    dependency 'com.google.guava:guava:18.0'
  }
}

dependencies {
  testCompile 'org.assertj:assertj-core'
  testCompile 'org.assertj:assertj-guava'
}

assertj-guava-3.0.0.pom declares:

  <properties>
    <guava.version>15.0</guava.version>
    <assertj-core.version>3.0.0</assertj-core.version>
  </properties>

  <dependencies>
    <dependency>
      <groupId>com.google.guava</groupId>
      <artifactId>guava</artifactId>
      <version>[${guava.version},)</version>
    </dependency>
    <dependency>
      <groupId>org.assertj</groupId>
      <artifactId>assertj-core</artifactId>
      <version>[${assertj-core.version}, 3.99.0]</version>
    </dependency>

I expected that assertj-core version 3.4.1 declared in dependencyManagement will be used, but gradle dependencies --configuration testCompile shows latest 3.6.2 (as of today), and the same problem for guava:

:dependencies

------------------------------------------------------------
Root project
------------------------------------------------------------

testCompile - Dependencies for source set 'test' (deprecated, use 'testImplementation ' instead).
+--- org.assertj:assertj-core: -> 3.6.2
\--- org.assertj:assertj-guava: -> 3.0.0
     +--- com.google.guava:guava:[15.0,) -> 21.0
     \--- org.assertj:assertj-core:[3.0.0, 3.99.0] -> 3.6.2

(*) - dependencies omitted (listed previously)

BUILD SUCCESSFUL

Total time: 0.703 secs

Declaration of exclusions in dependencyManagement doesn't help, however declaration of exclusions on dependency helps:

dependencies {
  testCompile 'org.assertj:assertj-core'
  testCompile('org.assertj:assertj-guava') {
    exclude group: '*'
  }
  testCompile 'com.google.guava:guava'
}

forcing of version via resolutionStrategy also helps:

configurations.all {
  resolutionStrategy {
    force 'com.google.guava:guava:18.0'
    force 'org.assertj:assertj-core:jar:3.4.1'
  }
}

gradle --version:

------------------------------------------------------------
Gradle 3.4
------------------------------------------------------------

Build time:   2017-02-20 14:49:26 UTC
Revision:     73f32d68824582945f5ac1810600e8d87794c3d4

Groovy:       2.4.7
Ant:          Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM:          1.8.0_121 (Oracle Corporation 25.121-b13)
OS:           Linux 4.1.15-gentoo-r1 amd64

In case of Maven pom.xml:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>org.example</groupId>
  <artifactId>example</artifactId>
  <version>1.0-SNAPSHOT</version>

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.assertj</groupId>
        <artifactId>assertj-core</artifactId>
        <version>3.4.1</version>
      </dependency>
      <dependency>
        <groupId>org.assertj</groupId>
        <artifactId>assertj-guava</artifactId>
        <version>3.0.0</version>
      </dependency>
      <dependency>
        <groupId>com.google.guava</groupId>
        <artifactId>guava</artifactId>
        <version>18.0</version>
      </dependency>
    </dependencies>
  </dependencyManagement>

  <dependencies>
    <dependency>
      <groupId>org.assertj</groupId>
      <artifactId>assertj-core</artifactId>
    </dependency>
    <dependency>
      <groupId>org.assertj</groupId>
      <artifactId>assertj-guava</artifactId>
    </dependency>
  </dependencies>
</project>

versions resolved as expected - mvn -V dependency:tree:

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
Maven home: /usr/share/maven-bin-3.3
Java version: 1.8.0_121, vendor: Oracle Corporation
Java home: /home/godin/.java-select/versions/jdk1.8.0_121/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.1.15-gentoo-r1", arch: "amd64", family: "unix"
[INFO] Scanning for projects...
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building example 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ example ---
[INFO] org.example:example:jar:1.0-SNAPSHOT
[INFO] +- org.assertj:assertj-core:jar:3.4.1:compile
[INFO] \- org.assertj:assertj-guava:jar:3.0.0:compile
[INFO]    \- com.google.guava:guava:jar:18.0:compile
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.996 s
[INFO] Finished at: 2017-03-01T02:04:28+01:00
[INFO] Final Memory: 12M/240M
[INFO] ------------------------------------------------------------------------

[wilkinsona]

Thanks for providing such a detailed description of the problem.

This is a result of the fix for #77 which means that the plugin deliberately doesn't manage the versions of dependencies with a dynamic version. That fix may have been a bit broader than necessary, though. Any dependency, declared locally or being pulled in transitively, that has a dynamic version is skipped when applying dependency management. Only skipping locally declared dependencies would, I believe, still address #77 and would also address the problem reported here.

[Godin]

For posterity: in case of assertj-guava solution is simple - upgrade to newer version 3.1.0 that doesn't use range. But I can imagine that in a more complex scenarios might be critical to have at least working exclusions.

So thank you for considering this for fix. And you can count on me in testing.