With Gradle 6.1.1 we get the following if we use
The runtimeClasspath configuration has been deprecated for dependency declaration. This will fail with an error in Gradle 7.0. Please use the implementation or compileOnly or runtimeOnly configuration instead.
This actually removes a valid and needed configuration and functionality of Gradle. It should not be removed. It could be replaced with something equivalent but it needs to exist. Current documentation does not state what the replacement should be. In fact, it does not even state that it is deprecated for 6.2. See:
Here are the saved versions in case the above changes:
Here are the reasons:
- It provides a common way to obtain everything that is needed at runtime. It isn’t just Gradle itself or tools built by Gradle needing this. Our scripts and surrounding ecosystem also rely on this to obtain “everything” rather than (a) having to know what actually goes in (
runtimeOnly) and (b) actually reference all. Note that tools may not, in fact, know about other configurations that
runtimeClasspathhas been set to “
extendsFrom” and would need separate setup for that.
- Gradle isn’t strict with transitive dependencies but it allows us to configure it to be strict. Safe and strict compile time dependencies should be NOT transitive (by default they are but can be configured not to be). In other words, if we use an unstated dependency the compilation should fail precisely because we didn’t state it as needed. Runtime dependencies ARE and should be transitive. But, at the same time the (unstated) transitive dependencies of compilation dependencies should nevertheless appear as (transitive) runtime dependencies. Gradle does not do this on its own by default but is easy to accomplish by adding the same compilation (
implementation) dependency again as a runtime dependency and have the
implementationconfiguration declared as NOT transitive. Duplication can be avoided with a little bit of utility scripting (we do that). Right now we do this dual declaration with
runtimeOnlywould not be the correct configuration to use as it implies that these aren’t used during compilation. Even if Gradle itself may not care if this is polluted with other stuff, other tools in the ecosystem do. Even if we wanted to declare our own “runtimeFromTransitiveImplementation” configuration, we would not have a proper way to “plug” it into any common configuration that the rest of Gradle ecosystem would know about (e.g.
runtimeClasspath.extendsFrom runtimeFromTransitiveImplementation) - that brings us full circle back to the issue #1.
Much of the above applies to RuntimeClasspath and also compileClasspath and CompileClasspath.