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
(Björn Kautler)
April 19, 2023, 8:53am
2
See
opened 04:44PM - 05 Aug 21 UTC
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.
```
opened 11:01AM - 13 Oct 21 UTC
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.
gradle:master
← gradle:frauboes/dependencies/plugins
opened 11:23AM - 27 Jan 23 UTC
* Fixes https://github.com/gradle/gradle/issues/18620
* Fixes https://github.co… m/gradle/gradle/issues/17963
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}" }