This message was deleted.

My recommendation is to use an included build unless you have a good reason not to. But actually, some of the pros are mitigated with Gradle 8 where

buildSrc

is made even more similar to an included build. But I personally would still prefer an included build.

I'm currently trying with

buildSrc

, and I'm running into an issue when trying to apply detekt as part of my conventional plugin. Apparently, applying "io.gitlab.arturbosch.detekt:detekt-gradle-plugin" also requires to apply "org.jetbrains.kotlin:kotlin-gradle-plugin", but if I do, I get

The request for this plugin could not be satisfied because the plugin is already on the classpath with an unknown version, so compatibility cannot be checked.

Am I correct to assume that this problem will disappear with an included build as the latter is no implicitly on the classpath of all projects like

buidSrc

is?

I presume that error is caused by defining a plugin version in two conflicting places, and that problem only has one solution (define the plugin version once). It won’t be helped by using buildSrc or build-logic. Which plugin is Gradle complaining about?

It's

* What went wrong:
Error resolving plugin [id: 'org.jetbrains.kotlin.jvm', version: '1.8.21']
> The request for this plugin could not be satisfied because the plugin is already on the classpath with an unknown version, so compatibility cannot be checked.

and you’ve got a dependency on the plugin in

buildSrc/build.gradle.kts

dependencies {}

?

Yes, because detekt does not work without it.

if so, then you just have to remove the version from all

plugins {}

blocks, in subprojects and in pre-compiled script plugins

plugins {
  kotlin("jvm") // no need for a version - it's defined in buildSrc/build.gradle.kts
}

In `buildSrc/build.gradle.kts`:

dependencies {
    implementation(files(libs.javaClass.superclass.protectionDomain.codeSource.location))

    // See <https://docs.gradle.org/current/samples/sample_convention_plugins.html#applying_an_external_plugin_in_precompiled_script_plugin>.
    implementation(libs.detektPlugin)
    implementation(libs.kotlinPlugin)
}

Using an included build could maybe help, yes, if all places are using the same version. I'm not 100% sure though, as I'm not fully sure when the version is considered unknown and when not. But with

buildSrc

it should probably always be unknown as it does not take part in conflict resolution but is just prepended to the classpaths using a parent class loader. But removing all other plugin versions like Adam suggested might also make it work with

buildSrc

, yes.

if so, then you just have to remove the version from all

plugins {}

blocks, in subprojects and in pre-compiled script plugins

Thanks, looks like that was the missing bit.

I've recently went for the build-logic convention plugins and I've to say I like it more than the buildSrc. I find it more flexible. I'm still not good at writing plugins and have a lot of stuff I don't know how to do but I think it is also an opportunity to learn Gradle better. I don't know what is the recommended way. I just like this one more than buildSrc.