CODEWITHSUNDEEP
gradlekotlinshadowjar
Rob Oxspring
Rob Oxspring

Reputation: 2955

Should I shadow Kotlin when writing a Gradle Plugin

I'm writing a plugin to extract some boilerplate from a selection of existing Gradle build scripts. The existing build scripts are primarily written in Groovy and compiling Java.

To build my plugin I'm using the Gradle Kotlin DSL and figured I'd take the opportunity to write the plugin in Kotlin too. This all works but now my plugin has a huge dependency on Kotlin - and the Gradle docs specifically recommend minimizing external libraries.

Java and Groovy plugins avoid this because Java & Groovy are a shared dependency with Gradle, but Kotlin isn't a shared pre-requirement and so we then have to be concerned about potentially conflicting Kotlin versions needed by different plugins.

I figure I should move forward with one of the following approaches but am not clear which:

  1. Just list Kotlin's stdlib as a standard dependency and trust Gradle to sort things out.

    This works for one plugin, but should I expect problems when another plugin is also being used but depending on a different Kotlin?

  2. Build some sort of uber shadowJar shadowing Kotlin libraries for my plugin

    Implying that every plugin I write like this will be 10s of MB bigger than necessary.

  3. Give up on Kotlin based plugins and rewrite in Java/Groovy

    Would be a shame to give up on the new goodness but might be better to avoid the above sins.

Recommendations welcome!

Upvotes: 3

Views: 625

Answers (2)

Rob Oxspring
Rob Oxspring

Reputation: 2955

Raised this in Gradle Community Slack and was recommended to use Gradle's kotlin-dsl plugin to automatically configure dependencies on gradleApi() and embeddedKotlin() versions, and therefore whatever Kotlin version is bundled with Gradle's Kotlin DSL support.

I was concerned that this might introduce a dependency on the calling script using Kotlin DSL, but I've tested with a Groovy script and have been able to use my plugin. I assume that it does still depend on a version of Gradle with Kotlin DSL support though - i.e. 4.0+.

Upvotes: 1

Selcaby
Selcaby

Reputation: 91

Since your plugin is replacing boilerplate and is presumably not destined for public release, would it make sense to write it as a script plugin in the Gradle Kotlin DSL? That way a new enough Gradle should be able to understand it natively.

Upvotes: 1

Related Questions