I'm working on a gradle plugin (https://github.com/pschichtel/tiny-jib) that produces, among other things, a JSON file, which is meant to be consumed later down the line during the build. Currently I'm using jackson to generate the JSON, but I'd prefer to use kotlinx.serialization with its compiler plugin, thus also allowing downstream users to use the generated KSerializer. When using the kotlinx.serialization compiler plugin I have to align it with the kotlin version, but I'm not sure how I would go about that without manually trying to stay in sync with gradle. Any ideas? Or any pointers to plugins already doing this?

your plugin should be using Gradle's embedded Kotlin in

build.gradle.kts

through either one of

plugins {
    `kotlin-dsl`
    `embedded-kotlin`
}

and you can use other Kotlin plugins with matching version

plugins {
    kotlin("plugin.serialization") version embeddedKotlinVersion
}

Out of curiosity, how does

embeddedKotlinVersion

behave if the plugin is applied to a version of Gradle that does not support Kotlin DSL yet? And what would be the right solution to make a plugin written in Kotlin still work with such old Gradle versions?

+1 to Sebastian question. If the plugin is published, you want to uncouple from

embedded-kotlin

. I wrote a plugin to help with this: https://github.com/GradleUp/Tapmoc

Gradle doesn't have a good built-in method for building plugins which target older Gradle versions. but you could also simply use older Gradle versions to build plugins

Using older versions of build tools is always a bit sad. There should be no reason to do this

we don't (officially) have the Gradle API separated out from the Gradle distribution unfortunately

there is since 9.0, right?

sorta experimentally, I remember the release notes noting some limitations… and it doesn't help with older versions. but yes, the Nokee artifacts have done great job (that's why I said "officially")

I don't think using

embeddedKotlin

for a published plugin is a good idea? For

buildSrc

or an included build like

build-logic

this is perfectly fine. But for a published plugin, you tie to that version then. You should use a Kotlin version that is supported by the oldest Gradle version you want to support. Actually I would for compatibility reasons and less problems reasons never write a public Gradle plugin in Kotlin or Groovy, but always in the lowest Java version supported by the lowest Gradle version I want to support, so most probably in Java 8. 🙂

Sure, but the latter is not an option for us Kotlin fanboys 😉 I actually want to be able to use the latest & greatest Kotlin (and maybe its stdlib) in my plugin, but I still want it to work even with Gradle versions that themselves do not support Kotlin DSL yet.

In versions that do not have Kotlin DSL at all, this will most probably even be easier as there Gradle does not control the Kotlin version available at runtime. 😄

When did Gradle start supporting Kotlin? 5.0 I think? That's been a while...

thanks everyone for the discussion, I didn't notice until now because my work-slack wasn't logged in here. Decoupling the kotlin version used by the plugin from the one used by kotlin makes total sense to me. @Martin was kind enough to send a PR doing that (among other things), thanks for that!