Okay, I finally got a working project with version...

# gradle

[Arjan van Wieringen]

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.

[PoisonedYouth]

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?

[Arjan van Wieringen]

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

[Arjan van Wieringen]

P.s. this is according to Gradles own example https://docs.gradle.org/current/samples/sample_convention_plugins.html#compiling_convention_plugins

[Adam S]

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

[PoisonedYouth]

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

[Arjan van Wieringen]

What would be the benefit of this? buildSrc is just the default includeBuild.

[PoisonedYouth]

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).

[Adam S]

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?

[Arjan van Wieringen]

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

[PoisonedYouth]

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.