Okay, I finally got a working project with version catalogs and precompiled scripts plugins for my personal projects. There were some weird things though: • when adding the plugins in the

buildSrc

, because I needed them in the precompiled scripts, I needed to add them to the

implementation

block. However this resulted in the fact that they were on the classpath in the other projects as well and there I only needed to apply them when needed. This felt a bit weird, but writing it out it makes sense I think.... but it is not something I did before. Normally I would define the plugins in the root

build.gradle.kts

with the

apply

set to

false

• IntelliJ IDE autocomplete and code-highlighting is terribly broken in the plugins. The only cure was restarting the IDE a lot of times. This made development a bit hard. I have the latest IDE. • Getting the plugins from the version-catalog in the

implementation

of the the

buildSrc

I had to do weird string interpolation and separate getting of the plugin-id and plugin-version. However, I learned a lot I think, but Gradle is still a very complicated powerful beast for me. I have the working repository here: https://github.com/avwie/kotlinx Maybe if some people have some comments on how to do it better I'd like to know.

The definition of the Plugins in the build.gradle.kts of the buildSrc is really not the straight forward way. In my projects I add the necessary plugins in the [library] section of the libs.versions.toml to not need to do the string operations when defining them. What is the reason to not migrate the convention plugins to own submodule?

I thought so. The reason to not migrate is just not knowing that that is the convention. That's why I ask it here 😉

defining plugin versions in

buildSrc/build.gradle.kts

this is my preferred way of defining plugins! It means that I can apply the plugins in convention plugins, or directly in projects, without versions - and they will always be aligned.

IntelliJ IDE autocomplete and code-highlighting is terribly broken in the plugins

it’s gotten better recently, but yes, it still fails a lot. Could you add a link to your project to this ticket so it can be investigated? https://youtrack.jetbrains.com/issue/KTIJ-19446

Getting the plugins from the version-catalog in the

implementation

of the the

buildSrc

I prefer defining the Maven coordinates of a plugin, not the plugin ID, in

libs.versions.toml

- it’s much more simple. the

[plugins]

block isn’t so useful for buildSrc

this is my preferred way of defining plugins! It means that I can apply the plugins in convention plugins, or directly in projects, without versions - and they will always be aligned.

The same you can do if defining the convention plugin in submodule and include by "includeBuild(...)" in your settings.build.gradle.kts

What would be the benefit of this?

buildSrc

is just the default

includeBuild

.

As to the documentation it's planed to make buildSrc an included build, but not done yet (see https://docs.gradle.org/current/userguide/composite_builds.html).

there’s some sort of drawback where if you make a change in buildSrc, then buildSrc must be recompiled, and then Gradle must do a full rebuild of all the build config. In theory an included-build is more isolated, so that full rebuild isn’t required. I think it’s a pretty tenuous reason to convert from buildSrc to included-build. How often does buildSrc change? Not a lot. And even if a full rebuild is required, for most projects it’s usually not a heavy hit. Meanwhile, included-build plugins are slightly less well supported by IntelliJ, and can be much more fiddly to set up, which is much more annoying than a slower build. If you’ve got a Gradle project with 10's of subprojects, and lots of different conventions, and everyone’s very Gradle-savvy… then maybe it’s worth it?

Well, I tried refactoring it and it was easy. TBH it looks a bit cleaner now as well.

Absolutely true, moving the convention plugins to own module is just an other option, als already mentioned it does not give me that game changing advantage.