"Failed to determine latest version..." when custom selection rules are active

[vitalyster]

When dependency have only one version available and this version is rejected by selection rules I got the following:

Failed to determine the latest version for the following dependencies (use --info for details):
 - org.apache.commons:commons-imaging
The exception that is the cause of unresolved state: Could not find any version that matches org.apache.commons:commons-imaging:+.
Versions rejected by component selection rules: 1.0-alpha1
Searched in the following locations:
  - https://repo.maven.apache.org/maven2/org/apache/commons/commons-imaging/maven-metadata.xml
  - https://jcenter.bintray.com/org/apache/commons/commons-imaging/maven-metadata.xml
  - https://jcenter.bintray.com/org/apache/commons/commons-imaging/

I'm not sure how to handle this case correctly but at least to should not fail

[ben-manes]

I think listing it as not resolvable is the only correct behavior. You could whitelist it in your selection rule to not reject that coordinate.

[Vampire]

I second OP, was about to report the same. I make my build fail if there are unresolved or outdated libraries. If I have for whatever reason the need to depend on some version I usually filter out with component selection, the build fails.

So the behavior is:

current version: 1.0.0 available version: 1.0.1-beta1 => lib is shown as up to date

current version: 1.0.1-beta1 available version: 1.0.1-beta2 => lib is not resolvable (for me fails)

I'd have expected the component selection rules to only be effective on the target versions, not on the currently declared versions.

What makes this even worse is, that it also affects hidden dependencies. I just added spotbugs to my build and suddenly the dependencyUpdates task fails as it cannot resolve slf4j-simple 1.8.0-beta4 which is added by the spotbugs plugin to the spotbugs configuration.

Due to that it is shown as unresolved library. If you would whitelist this lib / version, your plugin would then after that see it is in a hidden configuration and not list it at all in the output.

[ben-manes]

I'd have expected the component selection rules to only be effective on the target versions, not on the currently declared versions.

If you specify a dependencyUpdates.resolutionStrategy, we only apply it to the latest version query.

What makes this even worse is, that it also affects hidden dependencies.

Currently we ignore hidden dependencies, but we filter out hidden configurations (Configuration#isVisible). I don't know much about those. It sounds like that might solve your problem?

[Vampire]

If you specify a dependencyUpdates.resolutionStrategy, we only apply it to the latest version query.

No you are not or I'm getting you wrongly. Add e. g. com.github.spotbugs:spotbugs:4.0.0-beta1 as dependency while the resolution strategy excludes beta versions and it will be listed as unresolvable.

What makes this even worse is, that it also affects hidden dependencies.

Currently we ignore hidden dependencies, but we filter out hidden configurations (Configuration#isVisible). I don't know much about those. It sounds like that might solve your problem?

With hidden dependency I meant dependency in hidden configuration and as I just told you, you filter them out, but too late. First it fails with "cannot resolve" which makes it be shown as unresolved, then if you whitelist in the resolution strategy it is filtered out due to being hidden as the info logging output tells.

Just add the spotbugs gradle plugin and see the effect yourself.

[ben-manes]

Oh, I'm sorry - I meant we don't filter out hidden configurations. This was what I meant as a possible fix and pointing to the method to check on.

We do apply any resolutionStrategy on a configuration that is otherwise declared, as we do a copy.

[Vampire]

Oh, I'm sorry - I meant we don't filter out hidden configurations. This was what I meant as a possible fix and pointing to the method to check on.

Ah, I misunderstood then in the output and in #292. What you filter out are actually not hidden dependencies. What you filter out are default dependencies added to a configuration using Configuration#defaultDependencies that are used if nothing else is added to the configuration explicitly. What I still think should not be done.

So adding the dependencies to the hidden configuration actually is a workaround for #292 and it actually also is for this, but then it is listed as dependency which might be undesirable.

We do apply any resolutionStrategy on a configuration that is otherwise declared, as we do a copy.

Hm, strange, now I cannot reproduce with the explicitly added beta. Maybe I mislooked. And as I read again OP post, I have to say I agree with you, that unresolved state there is ok, as there is no version that bypasses the resolution strategy, I missed the part that it is the only version available.

But one thing is still left from my PoV. The default dependencies that behave strange if they don't pass resolution strategy. If I do

configurations.register("foo").get().defaultDependencies {
    add(dependencies.create("com.github.spotbugs:spotbugs:4.0.0-beta1"))
}

or

configurations.register("tools").get().defaultDependencies {
    add(dependencies.create("com.github.spotbugs:spotbugs:3.1.0-RC7"))
}

with rc and beta forbidden by resolution strategy, the dependency is shown as "Failed to determine the latest version for the following dependencies".

With rc and beta allowed, they are skipped from the output as they are default dependencies.

[ben-manes]

What you filter out are default dependencies added to a configuration using... What I still think should not be done.

That's fair. I don't have a strong view on this. It was confusing because you would see obscurely named dependencies, including ant, which users wouldn't recognize. If we could detect that they were default dependencies then we could annotate them and avoid that misunderstanding.

Hm, strange, now I cannot reproduce with the explicitly added beta.

And oddly now I can reproduce =)

The dependency does exist on maven, but the version would be rejected by the rule. But since we use org.slf4j:slf4j-simple:+ the version query and don't apply the filter on the original, I'm surprised as well.

The exception that is the cause of unresolved state: Could not find org.slf4j:slf4j-simple:1.8.0-beta4.
Searched in the following locations:
  - https://repo.maven.apache.org/maven2/org/slf4j/slf4j-simple/1.8.0-beta4/slf4j-simple-1.8.0-beta4.pom
  - https://jcenter.bintray.com/org/slf4j/slf4j-simple/1.8.0-beta4/slf4j-simple-1.8.0-beta4.pom

The default dependencies that behave strange if they don't pass resolution strategy.

Its definitely true that default dependency handling wasn't thought through, as it was a feature added after the initial version of this plugin. At the time I used a hack to filter them out. That might be interacting badly for you.

I meant we don't filter out hidden configurations.

I took a quick look and I'm not sure what hidden configurations are used, so the isVisible flag doesn't seem useful yet. A quick printout wouldn't have helped in your case.