https://gradle.com/ logo
Join Slack
Powered by
What is the best practice around kotlin-stdlib dep...
# plugin-development
j
What is the best practice around kotlin-stdlib dependencies in gradle plugins? since gradle provides a stdlib, should these be compileOnly? or is implementation dependency OK? if it is, are there considerations about the version that should be depended on?
m
Theorically it should be 
compileOnly
but everyone makes it 
implementation
. Make sure to use the version that is compatible with the version that your Gradle ships.
j
yeah... we have a convention plugin that adds the compileOnly dependency, and sets the apiVersion and languageVersion to our targeted gradle version... and then we set 
kotlin.stdlib.default.dependency=false
to avoid the runtime dependency. but transitive dependencies in runtime can cause drift, and I was trying to figure out the best way to go from there.
m
I wrote my own framework for that, it's called gratatouille
But you can use something else. Everything that runs in a separate classloader will work
I find it helps to reason in terms of: • wiring: this is the public API of your plugin and what users interact with. This MUST use a compatible version of kotlin-stdlib • task actions: this is the actual work being done. It's really hard, almost impossible to control the kotlin-stdlib there so it needs to run in a separate classloader
j
yeah task actions is a separate thing. Im just worried about leaking a newer version of stdlib as a runtime dependency
but does gradle force it to the embedded anyway?
m
It loads kotlin-stdlib in a parent classloader to your plugin
j
ah yeah ok
m
Gratatouille forces you to write your task actions in a separate module so you can't leak
It's a bit more setup but I sleep much better since then 🙂
2 Views
Open in Slack
PreviousNext
Powered by