Legacy configurations should be skipped

[Vampire]

Givne this trivial build:

./build.gradle.kts
plugins {
    java
    id("org.openjfx.javafxplugin") version "0.1.0"
    id("com.github.ben-manes.versions") version "0.51.0"
}

repositories {
    mavenCentral()
}

dependencies {
    implementation("org.openjfx:javafx-base:17")
}

./gradle/wrapper/gradle-wrapper.properties
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-7.6.4-bin.zip
networkTimeout=10000
validateDistributionUrl=true
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists

./settings.gradle.kts
rootProject.name = "foo"

If you execute the dependency updates task, it fails to resolve javafx-base. The reason is, that the legacy (consumable and resolvable) configuration default is checked which extends runtimeElements. It has the javafx-base dependency, but it does not have the necessary attributes set to properly select one of the variants, as those are only set on the proper resolvable configurations, i.e. runtime classpath and compile classpath for all source sets.

The plugin should probably better ignore those legacy configurations and only consider those that are resolvable but not consumable.

[ben-manes]

I assumed that the legacy configurations are scheduled for removal so this warning would go away? It must still be there assuming someone uses it, so if so then it should be resolved for them. I'd rather skip if something obvious, like no declared dependencies. Would that skip these naturally?

[ben-manes]

In the meantime, if annoying you, you can use filterConfigurations.

[Vampire]

I assumed that the legacy configurations are scheduled for removal so this warning would go away?

Yeah, hopefully one day. :-D

I'd rather skip if something obvious, like no declared dependencies. Would that skip these naturally?

Those legacy configurations can be used in a multitude of variations. And that they are still there is just for backwards compatibility. The "no declared dependencies" could indeed be a good marker. If someone is aware how to properly define the configurations, no legacies should be created by him. If someone is half-aware of how to do it properly, separating "dependencyScope" from "resolvable" configuration but does not set the properties properly, he probably does it wrong for both and the "dependencyScope" one would be left to be checked by the plugin. On the other hand, the "resolvable" one would probably have the necessary attributes. But currently it would check both and then also have a problem with missing attributes. On the other hand focussing on the ones without dependencies would also not be right, as another common bad pattern is to have one dependency that is used for "dependencyScope" and "resolvable" at the same time. So the question is how much or which legacy patterns one wants to support.

In the meantime, if annoying you, you can use filterConfigurations

Ah, perfect, forgot about that, thanks. This works perfectly fine:

tasks.dependencyUpdates {
    filterConfigurations = Spec {
        !it.isCanBeConsumed
    }
}