Gradle API dependency should allow a version argument

[ajoberstar]

Dependencies on Gradle's API should not be limited to the current Gradle version used by the build.

Expected Behavior

Provide options like:

dependencies {
  compile 'org.gradle:gradle-api:3.0'
}

Or if the JARs won't be published that way:

dependencies {
  compile gradleApi('3.0')
}

Current Behavior

dependencies {
  compile gradleApi() // always uses the API of the Gradle version used to run the build
}

Context

If I need to compile against Gradle 3.0 (since it's the minimum supported by a plugin) I shouldn't also be limited to building the plugin itself with Gradle 3.0. I can use TestKit to verify compatibility with older versions, but it would be nice to get compile errors if I was using an API that was too new.

Ultimately, I don't understand the case for gradleApi() being a special case dependency. Seems like it would be more straightforward to publish the Gradle API to a Maven repo like any other dependency in the Java community.

[bmuschko]

This could be somewhat addressed with the epic #1156. It will likely require splitting up Gradle core into modules and publishing them.

[mkobit]

+1 for this. I also agree with not understanding why gradleApi is a special case dependency. It seems like it should be something that akin to the provided scope in Maven.

This would be useful for a project I'm working on (https://github.com/mkobit/assertj-gradle). I would like to make sure it can be built and used against multiple Gradle versions and getting feedback during compilation time without having to write a bunch of Test Kit tests. It is even more a problem if I am using a build.gradle.kts (or soon, a settings.gradle.kts) which really limits the ability to use newer versions of Gradle while building and staying compatible for older versions.

[wilkinsona]

I’d like to see this too. My use case is building Spring Boot’s Gradle Plugin which supports Gradle 4.0+ and JDK 8, 9, and soon 10. We currently build the plugin using Gradle 4.0.x (to avoid accidental use of APIs that only exist in newer versions) but Gradle 4.0.x doesn’t work with JDK 10. Being able to build with and up-to-date version of Gradle but compile against the 4.0.x API would be a nice solution to the problem. The two alternatives I’ve thought of thus far are less than ideal:

1. Rely on integration tests and TestKit to catch incompatibilities with older versions
2. Rely on Animal Sniffer (assuming an API signature is available/could be produced) to catch usage of APIs that don’t exist in older versions

[JLLeitschuh]

Agreed.
I want to be able to write an adapter for spotless that can selectively use the old task API or the new task API depending upon what version the plugin is running in.

Being able to get access to the gradle API by version would be awesome.

[martinbonnin]

Also, it looks like gradleApi() puts the Kotlin stdlib version in the compileClasspath? I just got this as part as updating to Kotlin 1.5 (using Gradle 6.8):

w: Runtime JAR files in the classpath should have the same version. These files were found in the classpath:
    /Users/mbonnin/.gradle/wrapper/dists/gradle-6.8-bin/1jblhjyydfkclfzx1agp92nyl/gradle-6.8/lib/kotlin-stdlib-1.4.20.jar (version 1.4)
    /Users/mbonnin/.gradle/wrapper/dists/gradle-6.8-bin/1jblhjyydfkclfzx1agp92nyl/gradle-6.8/lib/kotlin-stdlib-common-1.4.20.jar (version 1.4)
    /Users/mbonnin/.gradle/wrapper/dists/gradle-6.8-bin/1jblhjyydfkclfzx1agp92nyl/gradle-6.8/lib/kotlin-stdlib-jdk7-1.4.20.jar (version 1.4)
    /Users/mbonnin/.gradle/wrapper/dists/gradle-6.8-bin/1jblhjyydfkclfzx1agp92nyl/gradle-6.8/lib/kotlin-stdlib-jdk8-1.4.20.jar (version 1.4)
    /Users/mbonnin/.gradle/wrapper/dists/gradle-6.8-bin/1jblhjyydfkclfzx1agp92nyl/gradle-6.8/lib/kotlin-reflect-1.4.20.jar (version 1.4)
    /Users/mbonnin/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-jdk8/1.5.0/65fbc439df2e4aad1f3769762d54534f1b564090/kotlin-stdlib-jdk8-1.5.0.jar (version 1.5)
    /Users/mbonnin/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-jdk7/1.5.0/f61904618ea7be07a66e0545ffe8dc2c70a19b77/kotlin-stdlib-jdk7-1.5.0.jar (version 1.5)
    /Users/mbonnin/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.5.0/29dae2501ca094416d15af0e21470cb634780444/kotlin-stdlib-1.5.0.jar (version 1.5)
    /Users/mbonnin/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-common/1.5.0/4080d69efca5e39e9b4972f125e40f1607bd6460/kotlin-stdlib-common-1.5.0.jar (version 1.5)

I assume using a regular dependency would get rid of these warning by resolving the Kotlin stdlib to 1.5.0 everywhere.

[martinbonnin]

@lacasseio pointed out to me that Nokee redistributes artifacts for each version of the Gradle API: https://docs.nokee.dev/manual/gradle-plugin-development.html#sec:gradle-dev-redistributed-gradle-api

The following works for me:

dependencies {
  compileOnly("dev.gradleplugins:gradle-api:$gradleVersion")
}

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.