This message was deleted.

replace

id("org.gradle.kotlin.kotlin-dsl") version "3.2.6"

with

`kotlin-dsl`

(including the backticks)

done, but same error 😕

I’m working on it 😉

xD fair, thanks 🙂 sorry for being trigger happy 😉

The request for this plugin could not be satisfied because the plugin is already on the classpath

This is a long story…. but basically there’s probably 10 different ways to set the version of a Gradle plugin, and most of those can’t be used together - yes it’s confusing! Under the hood it’s related to classpaths and Gradle needs to have a consistent classpath… Anyway, because you’re using buildSrc and you’ve defined the Kotlin Gradle plugin version in there (which is the correct thing to do), then this will enforce the Kotlin Gradle plugin version for the whole project. So, if you apply the Kotlin Gradle plugin anywhere else, then remove the version

// ./subproject-foo/build.gradle.kts

plugins {
  kotlin("jvm") // version "..."
}

and Gradle will pick up the version from

buildSrc/build.gradle.kts

The implementation dependency in the buildSrc adds the Kotlin Gradle Plugin to the classpath of your build, so you now need to use version-less plugin IDs in your build: the version is now managed by the dependency in the buildSrc

@Adam ah ok, I see, will do that then 🙂 what's the difference/reason for the backtick version of the kotlin-dsl, and why does ktor do it in the way I'm trying (tried to lean a bit on their config for inspiration 😉 )

hmmm I’m not sure why Ktor uses the plugin ID and version for Kotlin DSL https://github.com/ktorio/ktor/blob/b05dd2966b036d85179130af1abdc4ba8780ffa8/buildSrc/build.gradle.kts#L6 Basically

kotlin-dsl

is a shortcut for applying the Kotlin DSL with a version that’s compatible with the current Gradle version. You don’t have to use the recommended version, but it’s wise. Maybe Ktor needed a newer version of Kotlin DSL, but couldn’t update Gradle?

if there's a recommended version, I will definitely go for that - no reason to deviate (at least on the current level of development)

you should be able to ctrl+click on

kotlin-dsl

and it should take you to the source code, but it’s not working on my machine. I thought it was fixed… https://github.com/gradle/gradle/issues/20995

@Adam @Thomas Broyer thanks again, things seem to be working like a charm now and it's looking really great 🙏

nice to hear!

can you elaborate on that? i too have been bit by the versioning thing and specifying a custom nexus repo, trying to reduce the copypasta and inconsistencies. at this point, i'm not sure if i'm using a buildsrc build..i think i was able to switch to a composite build and have the conventions plugin be a

includeBuild

https://gradle-community.slack.com/archives/CAHSN3LDN/p1680685968225419?thread_ts=1680685390.572419&cid=CAHSN3LDN

There are many places where to define your plugin versions (and I'll limit this to the plugin DSL): • use

plugins { id("plugin.id") version "plugin.version" apply false }

in the root `build.gradle`/`build.gradle.kts` • use

pluginManagement { plugins { id("plugin.id") version "plugin.version" }

in the `settings.gradle`/`settings.gradle.kts` • use dependencies in `buildSrc/build.gradle`/`buildSrc/build.gradle.kts` (or the `build.gradle`/`build.gradle.kts` of a build included with

pluginManagement { includeBuild("build-logic") }

) The last one is the only way to get the plugins available in your precompiled script plugins (in the

buildSrc

or

"build-logic"

build), so I tend to declare all my plugin dependencies there and not use the others at all. Fwiw, I also use version catalogs, so I actually declare the versions in the version catalog's TOML file, and then use those to actually declare the dependencies. I never use the

plugins { alias(…) }

(except actually in the

buildSrc/build.gradle.kts

or

build-logic/build.gradle.kts

) Here's an example: https://github.com/tbroyer/gradle-incap-helper/blob/main/build-logic/build.gradle.kts (other relevant files:

settings.gradle.kts

,

build-logic/settings.gradle.kts

and of course

gradle/libs.versions.toml

) (also note that I actually use all those plugins from precompiled script plugins, but it doesn't really matter: the included build will be added to build's classpath, so any plugin in its dependencies is available to the build) This other example uses a

buildSrc

instead of an included build: https://github.com/tbroyer/auto-delegate

okay great, thank you that's helpful. the docs could really use improvement on clarity here, this breakdown you did would've been great to see on gradle's docs. there's a lot of "yeah do it this way it works fine ooooh you're using this well we didn't mention that but you need to do this a totally different way because you're using these types of builds"

there is a new doc page in the works for ‘how to write a plugin using Kotlin’ https://github.com/gradle/gradle/pull/24286

ooo excellent thanks i'll take a look

btw there’s usually not much difference between using buildSrc and included-build for convention plugins. I prefer using buildSrc because it’s a little bit simpler, but included-build can be really useful in some cases.

There used to be more differences between included builds and buildSrc, see the Gradle 8 release notes: https://docs.gradle.org/current/release-notes.html#improvements-for-buildsrc-builds

yeah, i noticed that 8 has made a lot of the gotchas less. makes me wonder, with parity so similar, what's the point of each at this point?