Suppose you want to create a simple library package that assists in developing Gradle plugins or otherwise enhance build scripts. As such, you pull in something like this:
Suppose you want to make your library package usable with different versions of the Gradle API; is there a suitable replacement for gradleApi() that would decouple the version of Gradle used to build the project and the version of Gradle you are designing the library around?
The toolbox plugins and the redistributed Gradle API are two different things. They work together, but you can use one without the other. I don’t support kotlin-dsl because, in terms of backward and forward compatibility, it’s a nightmare to do properly. I’m not saying we won’t add support for it, but we are sticking to what works for now.
You can directly look at the Gradle API project. Note that “library that supports plugins” is a bit of undefined behaviour in the Gradle ecosystem. You can’t deploy a no-plugin JAR to the plugin portal. However, because of the “implementation-ish details” where Maven Central is accessible via the Gradle Plugin Portal, you can publish your library to Maven Central. Your plugin can then depend on the library, and everything will work correctly. As you can see, it’s a bit of a known undocumented feature.
In theory, a “supporting library for Gradle plugins” should depend on the Gradle API using compileOnlyApi (when available), but only if the Gradle type leaks into your library’s public API. Otherwise, you should use compileOnly but never implementation (when using the redistributed JARs) because they will leak into your library and get pulled at runtime, resulting in two Gradle runtimes. It shouldn’t cause any crash but will cause a 100MB additional download.