Maybe another noob question here, but would it be ...

# gradle

[Arjan van Wieringen]

Maybe another noob question here, but would it be possible for me to create a custom gradle plugin that does the following:
• apply multiplatform, compose and publishing plugins
• set some sensible defaults
• add some basic dependencies
The reason I want this is that I want to have one starting point for all my projects with all the versions correctly set. I then only want to apply this plugin to get started.

Would the preferred way be a real Gradle plugin, or would it be possible in a precompiled script plugin?

[Adam S]

yeah, that’s super easy to do

precompiled script plugins are very easy to make, so I’d recommend that first

If you’re working in a large organisation and you have tonnes of projects that you want to make sure are aligned, then you can think about publishing a plugin with these conventions - but even then it’s usually a lot of hassle for not much benefit (imho)

[Adam S]

for version alignment, you could also consider

• version catalogs (libs.versions.toml), so all the dependencies and versions are in one file
• version platforms (Java Platform Plugin), which is kind of like making your own BOM, so you can define dependencies without versions in projects and the Platform will align them
https://docs.gradle.org/current/userguide/platforms.html

[Arjan van Wieringen]

Thanks for your reply. The precompiled script plugin is easy to publish as well right?

[Adam S]

I think so, but I’ve never done it. It’s relatively easy to convert from my-convention.gradle.kts to MyConvention.kt

[hfhbd]

I think you even don't need to convert them: https://docs.gradle.org/current/samples/sample_publishing_convention_plugins.html#publishing_convention_plugins

[Adam S]

yes sorry, my previous message was ambiguous. I should have said “Even if it’s not possible, it’s relatively easy to convert them”

[Vampire]

Precompiled script plugins are real plugins. They are just some syntactic sugar on top.

[Vampire]

And yes, what you describe is exactly the recommended idiomatic approach. Having a convention plugin that does what you want and then apply just that.

[Arjan van Wieringen]

Ah, I have refactored everything to use the libs.version.toml, but sadly this can not be used in a (precompiled) plugin.

[Arjan van Wieringen]

I think I maybe overcomplicated stuff. My goal was to create a gradle plugin which I can use in a target project which sets up a lot of basic dependencies and plugins to develop a compose desktop application. This means: compose plugin, coroutines dependencies, some serialization plugin, proper Kotlin version etc etc.

[Vampire]

Ah, I have refactored everything to use the libs.version.toml, but sadly this can not be used in a (precompiled) plugin.

Well, that's only partly correct.
You can use the string-y untyped API to access the version catalog.
Or you can use the hack-around I described in the according issue on GitHub.

I think I maybe overcomplicated stuff. My goal was to create a gradle plugin which I can use in a target project which sets up a lot of basic dependencies and plugins to develop a compose desktop application. This means: compose plugin, coroutines dependencies, some serialization plugin, proper Kotlin version etc etc.

As I said, that's exactly the idiomatic way and is called convention plugin. Whether you implement it in a standalone project, in an included build, in buildSrc, as "real plugin", as precompiled script plugin, ... is not important. 🙂

[Arjan van Wieringen]

Thanks! I will look into that.

[Arjan van Wieringen]

@Vampire Maybe I am overlooking it, but where is this Github issue you mentioned?

[Vampire]

https://github.com/gradle/gradle/issues/15383

[Arjan van Wieringen]

Great. Thanks. Sadly it doesn't really work in a plugin block for now, if I am correct because the Groovy DSL is more restrictive

[Vampire]

For Groovy DSL you do not need my hack-around at all, but yeah, in plugins block it works in neither DSL in a precompiled script plugin

[Arjan van Wieringen]

Damn 😞 So in a precompuled script plugin I can't enable a specific version of a plugin then.

[Vampire]

Not in the plugins block.
But you could probably use the legacy apply to do it.

[Adam S]

if you add the plugin’s Maven coordinates (not the plugin ID) to dependencies {} in buildSrc/build.gradle.kts then when you apply the plugin in the pre-compiled script plugin, it will choose that version

[Adam S]

and you can use libs.versions.toml in buildSrc/build.gradle.kts

[Arjan van Wieringen]

Okay, but will it pick the correct version when I publish the pre-compiled plugin and apply the plugin in a completely new project?

[Adam S]

yes, I’m pretty sure it will. I’m a little uncertain because I don’t fully understand the Gradle mechanisms. I do know that Gradle generally recommends against applying a specific plugin, and instead leave that up to the plugin-consumer.

https://docs.gradle.org/current/userguide/implementing_gradle_plugins.html#reacting_to_plugins

[Vampire]

Ah, yeah, @Adam S is completely right of course.
In a precompiled script plugin you cannot apply a plugin with version anyway, can you?

Regarding letting the consumer decide, that's not really correct.
If you want to configure a plugin in case it is applied, then you react to it.
But you can of course apply a plugin with a specific version if you want that.
It's just two different use-cases for a convention plugin.

[Stylianos Gakis]

Here’s a great place to look at a project which does exactly what you are asking for and can copy basically the entire thing. https://github.com/android/nowinandroid/tree/main/build-logic

One convention plugin example from in there which adds dependencies https://github.com/android/nowinandroid/blob/main/build-logic/convention/src/main/kotlin/AndroidFeatureConventionPlugin.kt
And one convention plugin example which applies compose too https://github.com/android/nowinandroid/blob/main/build-logic/convention/src/main/kotlin/AndroidLibraryComposeConventionPlugin.kt

[Arjan van Wieringen]

This is amazing. Thanks!