Using Version Catalogs with Precompiled Script Plugins

kelvSYC · April 19, 2023, 4:50am

Suppose I have a precompiled script plugin which contains something like

plugins {
    // Picking a random plugin out of a hat here
    id("org.jlleitschuh.gradle.ktlint")
}

And suppose in the project I have a version catalog like so:

[plugins]
# Version omitted for the sake of an example
ktlint="org.jlleitschuh.gradle.ktlint"

According to the instructions, I need to declare this plugin as an implementation dependency in order for the precompiled script plugin to function properly. Given the catalog above, how would I populate the dependencies block in my build.gradle.kts?

Vampire · April 19, 2023, 8:53am

See

github.com/gradle/gradle

Accept plugin declarations from version catalog also as libraries

opened 04:44PM - 05 Aug 21 UTC

Vampire

a:feature 🌱 onboarding in:dependency-version-catalog in:dependency-declarations

In some situations you need some plugin as plugin but also as dependency, for ex…ample when using the plugin also in some precompiled script plugins build. Or you develop a Gradle plugin that depends on plugin X but also uses plugin X in the same version for its own build. It would be nice if you would not have to list the plugin, respectively its library coordinates twice in the version catalog, but instead just do `implementation(libs.plugins.foo)`. Even if you only need the plugin as dependency in a build that uses the plugin in a precompiled script plugin it would be nice if it just works, so that you don't have to figure out the actual coordinates or remember the naming convention for the marker artifacts, but would be able to simply use the plugin declaration from the version catalog. ### Expected Behavior `implementation(libs.plugins.foo)` should work as expected ### Current Behavior in 7.2-rc-1 ```text Could not resolve all dependencies for configuration ':compileClasspath'. Cannot convert the provided notation to an object of type Dependency: org.gradle.api.internal.artifacts.dependencies.DefaultPluginDependency@38e8aa91. The following types/formats are supported: - Instances of Dependency. - String or CharSequence values, for example 'org.gradle:gradle-core:1.0'. - Maps, for example [group: 'org.gradle', name: 'gradle-core', version: '1.0']. - FileCollections, for example files('some.jar', 'someOther.jar'). - Projects, for example project(':some:project:path'). - ClassPathNotation, for example gradleApi(). Comprehensive documentation on dependency notations is available in DSL reference for DependencyHandler type. ```

github.com/gradle/gradle

Add a DSL to declare Gradle Plugins dependencies

opened 11:01AM - 13 Oct 21 UTC

gmazzo

a:feature in:kotlin-dsl in:groovy-dsl in:dependency-declarations

### Expected Behavior Have a dedicated DSL in `DependencyHandler` to declare a …dependency on a Gradle Plugin. ```kotlin fun DependencyHandler.plugin(id: String, version: String) = create("$id:$id.gradle.plugin:$version") ``` or directly into the main interface: ```java public interface DependencyHandler extends ExtensionAware { default Dependency plugin(String pluginId, String version) { return create(pluginId + ":" + pluginId + ".gradle.plugin:" + version); } } ``` So you can do: ``` dependencies { implementation(plugin("org.gradle.android.cache-fix", version = "2.4.4")) } ``` ### Current Behavior We need to declare a regular dependency either by knowing the Plugin's main artifact coordinate or using its "$pluginId:$pluginId.gradle.plugin" coordinate alias. ### Context Creating custom plugins (or migrating scripts into them) that are built upon others is becoming a standard (at least for us) with the recent tooling introduced by the `buildSrc` capability of compiling `src/main/kotlin/**.gradle.kts` files into ad-hoc plugins you can later use in your build logic. Those plugins won't accept a version, so you are forced to declare them as an `implementation` dependency in the `buildSrc` module. Having a similar syntax for easily migrate from the root `plugins` closure to a `dependency` will simplify and facilitate that migration. I can work on a PR if the idea sounds good to you. Let me know which implementation option will you prefer.

So hopefully in 8.3 there is a built-in way.

In the meantime you can use a manual work-around like

dependencies {
    implementation(libs.plugins.ktlint.dependency)
}

val Provider<PluginDependency>.dependency
    get() = map { "${it.pluginId}:${it.pluginId}.gradle.plugin:${it.version}" }