gradle-versions-plugin: Failures and warnings with Gradle 6.8-milestone-1
When using Gradle 6.8-milestone-1 I get the following warnings for gradle dependencyUpdates:
$ gradle dependencyUpdates
> Task :dependencyUpdates
Failed to resolve ::-api
Failed to resolve ::-runtime
Failed to resolve ::api
Failed to resolve ::apiElements
The archives configuration has been deprecated for resolution. This will fail with an error in Gradle 7.0. Please resolve the compileClasspath or runtimeClasspath configuration instead. Consult the upgrading guide for further information: https://docs.gradle.org/6.8-milestone-1/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations
Failed to resolve ::bootArchives
The compile configuration has been deprecated for resolution. This will fail with an error in Gradle 7.0. Please resolve the compileClasspath configuration instead. Consult the upgrading guide for further information: https://docs.gradle.org/6.8-milestone-1/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations
The default configuration has been deprecated for resolution. This will fail with an error in Gradle 7.0. Please resolve the compileClasspath or runtimeClasspath configuration instead. Consult the upgrading guide for further information: https://docs.gradle.org/6.8-milestone-1/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations
Failed to resolve ::implementation
The runtime configuration has been deprecated for resolution. This will fail with an error in Gradle 7.0. Please resolve the runtimeClasspath configuration instead. Consult the upgrading guide for further information: https://docs.gradle.org/6.8-milestone-1/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations
Failed to resolve ::runtimeElements
Failed to resolve ::runtimeOnly
Failed to resolve ::sourceArtifacts
Failed to resolve ::testApi
The testCompile configuration has been deprecated for resolution. This will fail with an error in Gradle 7.0. Please resolve the testCompileClasspath configuration instead. Consult the upgrading guide for further information: https://docs.gradle.org/6.8-milestone-1/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations
Failed to resolve ::testImplementation
The testRuntime configuration has been deprecated for resolution. This will fail with an error in Gradle 7.0. Please resolve the testRuntimeClasspath configuration instead. Consult the upgrading guide for further information: https://docs.gradle.org/6.8-milestone-1/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations
Failed to resolve ::testRuntimeOnly
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 22 (10 by maintainers)
I’ve opened https://github.com/spring-projects/spring-boot/issues/24072.
Thank you for the update @juergenzimmermann. And thank you @wilkinsona for being so helpful and fixing this promptly.
hah, I didn’t mean to use that slang but was tired, and mistyped it like that 😆
I took a quick peek and the cause seems to be this Spring commit. It sets the base Java configurations to extend Spring’s own. Presumably when the child configuration is resolved it has to resolve its parent’s and causes the failure. When we ensure that the child’s copy is set to allow resolution (code), that must not override the parent and you see these failures.
I’m not super confident on how we should treat
canBeResolvedandcanBeConsumed. The explicit setting was used for backwards compatibility across older versions, when this change was incubating.@wilkinsona is a lot sharper than I am and maybe can advise on how to improve our usage.