Deprecation warnings regarding deprecated dependency declaration

[stefan6419846]

Running the plugin (./gradlew dependencyUpdates --warning-mode all) with current Gradle 8.0.2 raises the following warnings:

> Task :dependencyUpdates
The compileClasspathCopy configuration has been deprecated for dependency declaration. This will fail with an error in Gradle 9.0. Please use another configuration instead. Consult the upgrading guide for further information: https://docs.gradle.org/8.0.2/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations
The compileClasspathCopy2 configuration has been deprecated for dependency declaration. This will fail with an error in Gradle 9.0. Please use another configuration instead. Consult the upgrading guide for further information: https://docs.gradle.org/8.0.2/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations
The runtimeClasspathCopy configuration has been deprecated for dependency declaration. This will fail with an error in Gradle 9.0. Please use another configuration instead. Consult the upgrading guide for further information: https://docs.gradle.org/8.0.2/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations
The runtimeClasspathCopy2 configuration has been deprecated for dependency declaration. This will fail with an error in Gradle 9.0. Please use another configuration instead. Consult the upgrading guide for further information: https://docs.gradle.org/8.0.2/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations
The testCompileClasspathCopy configuration has been deprecated for dependency declaration. This will fail with an error in Gradle 9.0. Please use another configuration instead. Consult the upgrading guide for further information: https://docs.gradle.org/8.0.2/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations
The testCompileClasspathCopy2 configuration has been deprecated for dependency declaration. This will fail with an error in Gradle 9.0. Please use another configuration instead. Consult the upgrading guide for further information: https://docs.gradle.org/8.0.2/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations
The testRuntimeClasspathCopy configuration has been deprecated for dependency declaration. This will fail with an error in Gradle 9.0. Please use another configuration instead. Consult the upgrading guide for further information: https://docs.gradle.org/8.0.2/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations
The testRuntimeClasspathCopy2 configuration has been deprecated for dependency declaration. This will fail with an error in Gradle 9.0. Please use another configuration instead. Consult the upgrading guide for further information: https://docs.gradle.org/8.0.2/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations

With stacktrace enabled: stacktrace.txt

[ben-manes]

We copy and resolve all of your project configurations. So this is benign if you upgrade as it is being picked up dynamically. Also, I believe if you use the newer Java platform plugins then they lack the legacy configurations so it won’t show up.

[skagedal]

Shows up for me as well with Gradle 8.1.1 and a simple gradle init project. Not sure what is meant with "newer Java platform plugins" – if you use the latest Gradle it will use the latest Java platform plugin, right? Since that is bundled?

[ben-manes]

The Java plugin was reorganized so it’s usage is discouraged.

As indicated above, this plugin adds basic building blocks for working with JVM projects. Its feature set has been superseded by other plugins, offering more features based on your project type. Instead of applying it directly to your project, you should look into the java-library or application plugins or one of the supported alternative JVM language.

[skagedal]

Ahh, I see what you're saying now. However, it seems to happen also with the application plugin – this Gradle file reproduces it:

plugins {
    id 'application'
    id 'com.github.ben-manes.versions' version "0.46.0"
}

repositories {
    mavenCentral()
}

dependencies {
    testImplementation 'org.junit.jupiter:junit-jupiter:5.9.1'
}

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(17)
    }
}

application {
    mainClass = 'tech.skagedal.gradleinit.App'
}

tasks.named('test') {
    useJUnitPlatform()
}

But I guess this is an annoyance we'll just have to live with, and it will go away once these configurations are removed from Gradle? Or would there be a way to tell Gradle to suppress these warnings on the copied configurations?

[ben-manes]

At times I’ve thought about a user supplied configuration filter, but never found a use case beyond suppressing a warning. That seemed more errorprone than helpful due to likely misuse. I often run with —quiet (-q) which might hide these, which would be a good workaround for now.

[TWiStErRob]

I often run with —quiet (-q) which might hide these, which would be a good workaround for now.

Hey @ben-manes you might be running with -q, but as platform engineers (an audience of this plugin) we're trying to use the plugin AND also maintain the builds. However the amount of noise generated by this plugin makes it impossible to find actual build issues, here's an example: Let's say there's a warning in that build, which actually is using broken behavior, and we want to fix. We need to see the stack trace of it, but it's hidden among the other literally 10000 issues generated by #749 and #680, and this is not even a big project. The only very lucky thing is that this is isolated to actually running the plugin's tasks, so it's not blocking other maintenance.

[ben-manes]

There is no Gradle metadata for us to inspect on to ignore those, but you could use filterConfigurations to skip them explicitly.

[TWiStErRob]

Could we filter on these?

[ben-manes]

We always skip if not isCanBeResolved. You can filter on other configuration attributes, but a deprecated dependency may be unrelated to that. The task predicate gives you the configuration object to decide with.