Report Shows Same Dependencies With Different Actual Version in Current and Outdated Section

Using the default plugin configuration this is what shows up in my report:

The following dependencies are using the latest milestone version:
 - ch.qos.logback:logback-classic:none
 - ch.qos.logback:logback-core:none
 - com.fasterxml.jackson.core:jackson-annotations:none
 - ...

The following dependencies have later milestone versions:
 - ch.qos.logback:logback-classic [1.2.3 -> 1.3.0-alpha5]
     http://logback.qos.ch
 - ch.qos.logback:logback-core [1.2.3 -> 1.3.0-alpha5]
     http://logback.qos.ch
 - com.fasterxml.jackson.core:jackson-annotations [2.12.2 -> 2.12.3]
     http://github.com/FasterXML/jackson
 - ...

I’m using a BOM platform module with exactly one version for each dependency. That’s why I wonder how the report can introduce such ambiguity.

Is there a special meaning about the none versioned dependencies? If not it would make the report easier to understand if it didn’t have those. One way of excluding them would be in:

https://github.com/ben-manes/gradle-versions-plugin/blob/6f7b95d52cbbaa9023384b9c6fb84c54937f712a/src/main/groovy/com/github/benmanes/gradle/versions/updates/DependencyUpdatesReporter.groovy#L225-L228

where a custom filter could be applied to the passed dependencies.

---

I’m using version 0.38.0 of the plugin running with Gradle 6.7.1

[mroeppis]

There is a way to save such versionless dependencies but I don’t like it.

This would move the fix outside of the Resolver and inside DependencyUpdates: https://github.com/ben-manes/gradle-versions-plugin/blob/9bef5cb55bee63f2e51b3456c1172102cf4fb593/src/main/groovy/com/github/benmanes/gradle/versions/updates/DependencyUpdates.groovy#L67-L70

As can be seen we go over the projects and then over configurations associated with them. I suggest we save none versioned dependencies that appear only once in the resulting set of DependencyStatus. By doing so any none that has a real version equivalent, be it from the same or any other configuration, will be dropped.

Sadly such versionless dependencies will be reported up-to-date. As I mentioned before I’d prefer unresolved but that would mean to construct an instance of UnresolvedDependency containing a problem (Throwable) although there never was a problem resolving the latest version of that dependency (…due to the way query dependencies are built). That being said the clean way to go would be to create a new result category, e.g. undeclared version containing dependencies (not constraints) that were explicitly declared without version by the user.

I guess this won’t happen because it requires a bigger change (version mapping, reporting part). But bear in mind that saying “depX is up-to-date” is simply wrong if you can’t tell the version of depX. This isn’t about file dependencies as well since there is no reference to a file. Try declaring a dependency implementation G:A only. Gradle won’t complain when configuring the project. But as soon as you try to compile it says:

Execution failed for task ':compileGroovy'.
> Could not resolve all files for configuration ':compileClasspath'.
   > Could not find G:A:.
     Caused by: org.gradle.internal.resolve.ModuleVersionNotFoundException: Could not find G:A:.

This might be something to come back to in the near future. As for now it might be acceptable to leave the reporting as is and to change DependencyUpdates only.

What do you think?

[mroeppis]

Closing after merge of PR #522.