Incorrect version listed

[jklap]

I'm trying to troubleshoot three issues with the plugin suggesting versions that are already defined in my build.grade file.

The plugin is currently outputting

• com.google.code.gson:gson [2.7 -> 2.8.0]

And my build.gradle has:

• compile('com.google.code.gson:gson:2.8.0')

I did a gradle dependencies and it only listed 2.8.0, no 2.7.

Any suggestions on how I can further troubleshoot?

[ben-manes]

Does it print out the dependency twice? If there are multiple versions defined (e.g. different sub-projects, buildscripts vs project) then it tries to show each upgrade independently. So you might be checking compile and forgot about classpath.

I organize my projects with a central definition, e.g. see dependency.gradle. That way I can declare it like compile libraries.guava and update one location after running the task.

[jklap]

I had grepped the output of gradle dependencies and it is listed a couple of times (I suspected the same thing too), but always with the same version number, 2.8.0 (ie compile, testRuntime, etc).

[ben-manes]

If you can trim it down to a sample that I can run then I can help debug. Not sure what else would cause this.

[jklap]

Note that I'm using Spring Boot, which I know pulls in other dependencies, but I would have expected to see those listed in the dependencies output? Let me see if I can trim down..

Adding a trimmed down... suspect it's the Spring Boot Gradle plugin.. not sure what else it could be...

build.gradle.txt

[ben-manes]

Can you try gradle buildEnvironment to check the buildscript?

[jklap]

No issues there.

I suspect it's due to the Spring Gradle Dependency plugin... not you

• https://github.com/spring-gradle-plugins/dependency-management-plugin/

BUT, according to that doco, defining the dependency in dependencies should override the default version pulled in by the Spring plugin. Going to verify it's actually overriding now...

Confirmed-- the generated jar does contain 2.8.0.

So it is being overridden, but gradle-versions isn't seeing that fact?

[ben-manes]

Perhaps dependencyInsight would help you track it down.

Ran into compatibility problems with them in #97 with an overly restrictive resolution strategy. Using --info should log if the resolver rejects a version.

[jklap]

The end result is the right version... it's just the output of gradle-versions

Using version '2.7' for dependency 'com.google.code.gson:gson:2.8.0'
'com.google.code.gson:gson:+' has a dynamic version. Dependency management has not been applied
...
Comparing dependency (current: com.google.code.gson:gson:2.7, latest: 2.8.0)

[ben-manes]

Using version '2.7' for dependency 'com.google.code.gson:gson:2.8.0'

That would be the dependency chosen by the build

'com.google.code.gson:gson:+' has a dynamic version. Dependency management has not been applied

That would be the dependency query from the versions plugin, to discover the latest.

[jklap]

Curious-- the dependency chosen by the build ends up being 2.8 though? Let me md5 the gson jar just to make sure it's not a naming issue.

Verified the jar included is 2.8. So the final build is using 2.8.

[ben-manes]

Perhaps there is a resolution strategy that runs after to force a version, causing it to upgrade back to 2.8 after we inspect it? Definitely something strange going on.

[ben-manes]

I didn't notice you edited your previous comment to include a sample, sorry!

If you follow the dependency-management-plugin documentation to specify the version for the BOM it will be reported in the dependencyUpdates report as expected. I added the following to your sample,

dependencyManagement {
  dependencies {
    dependency 'com.google.code.gson:gson:2.8.0'
  }
}

I don't know why you're observing the 2.8.0 jar in the packaged result. When I add the application plugin and run distZip, I see that 2.8.0 is in the output even though the other plugin should be forcing to the older release. @wilkinsona can probably explain what is going on.

[ben-manes]

The problem appears to be due to when the dependency-management-plugin decides to restrict the version. I assume when you declare it explicitly in compile it honors it for that configuration only. The dependencyUpdates task, perhaps unnecessarily, copies the configuration before any inspection or manipulations. This copy appears to be restricted by the BOM rules, though I don't know why it should be treated any different from the original.

Specifically in Resolver#getCurrentCoordinates(configuration),

Configuration copy = configuration.copyRecursive().setTransitive(false)
LenientConfiguration lenient = copy.resolvedConfiguration.lenientConfiguration
...

If I remove copy and use configuration directly then your sample shows the report correctly. The copy is only queried so I think it is a safe change, but I'd like to learn from @wilkinsona about why it is incompatible.

[ben-manes]

Sorry, it is not a safe change due to the useSelectionRules section below. This adds resolution strategies to (a) support revision type querying and (b) restrict only depedencyUpdates to filter out betas. So the change cannot be made by this plugin without impacting any downstream tasks. While it is unlikely subsequent tasks would be called, its impolite to make irreversible modifications that change the build's behavior in a undesirable manner.

[wilkinsona]

The behaviour described here is rather surprising.

I assume when you declare it explicitly in compile it honors it for that configuration only

That's correct.

The dependencyUpdates task, perhaps unnecessarily, copies the configuration before any inspection or manipulations. This copy appears to be restricted by the BOM rules, though I don't know why it should be treated any different from the original.

The dependency management plugin uses a mixture of an action that is applied to each dependency in the configuration via its resolution strategy and a beforeResolve action on the configuration's ResolvableDependencies. It would appear that, when the configuration is copied, the former is included but the latter is not. This is what surprised me. It's the latter that looks at the configuration's dependencies to override dependency management with any versions on your dependency declarations. Its absence is causing the behaviour you are seeing.

I'm not sure what I can do about this. I need a hook point for when a configuration is about to be resolved as, at that point, all its dependencies are known to be in place and they can be used to override dependency management.

@jklap You can avoid the problem by declaring your dependencies slightly differently. If you override the version properties that are declared in Spring Boot's bom:

ext['gson.version'] = '2.8.0'
ext['mysql.version'] = '5.1.40'
ext['postgresql.version'] = '9.4.1211'

And then declare your dependencies without versions:

dependencies {
    compile('com.google.code.gson:gson')
    runtime('mysql:mysql-connector-java')
    runtime('org.postgresql:postgresql')
}

You should get the desired behaviour:

gradle dependencyUpdates
:dependencyUpdates

------------------------------------------------------------
: Project Dependency Updates (report to plain text file)
------------------------------------------------------------

The following dependencies are using the latest milestone version:
 - io.spring.gradle:dependency-management-plugin:0.6.1.RELEASE
 - com.github.ben-manes:gradle-versions-plugin:0.13.0
 - com.google.code.gson:gson:2.8.0

The following dependencies have later milestone versions:
 - mysql:mysql-connector-java [5.1.40 -> 6.0.5]
 - org.postgresql:postgresql [9.4.1211 -> 9.4.1212]

Generated report file build/dependencyUpdates/report.txt

BUILD SUCCESSFUL

Total time: 3.426 secs

[ben-manes]

I've reported this on the Gradle forum regarding the beforeResolve not being copied.

[ben-manes]

@jklap It sounds like 1.0.2-SNAPSHOT resolves this issue. Can you verify?

[ben-manes]

Closing due to being resolved in gradle/gradle#1567. Thanks @wilkinsona!