:gradle-intensifies: In the Kotlin team we've star...

# gradle

[tapchicoma]

gradle intensifies In the Kotlin team we've started looking into Kotlin DSL for Declarative Gradle. It is our chance to fix problems in existing KMP kts DSL without going through painful breaking changes. One of the challenges we have is how to design DSL for generic Kotlin library. Specifically configuration that applies to a family of Kotlin targets, not all targets. If you have some examples of shared configuration that you apply to subset of enabled targets in your existing library projects - please share them in the thread to this message. Also generic ideas on how Kotlin Library DCL DSL could look like are also welcome.

[eygraber]

This isn't a great API, but I mostly use these plugins to configure defaults for all modules in the root build.gradle.kts and never need to change values in the modules themselves.

My KGP setup does some work across all targets via sourceSets and tasks.

[hfhbd]

I would like to see a custom incubating DependencyHandler, and (current) best practices like using `Property`s everywhere, same like Action instead of functions with receivers.

But I am mostly very curios how the integration and extension for 3rd party plugins works. As a plugin author, supporting jvm and multiplatform (and android!) is hard/complex, especially if you want to write a code generator that needs to be wired to a correct sourceSet/variant.

[tapchicoma]

DCL provided by the plugin is more about most common configuration scenarios in the users projects. If you are doing customization for your needs - then you will need to create you own Declarative Software types and use existing KGP APIs to wire it properly.

[hfhbd]

Hm, you can extend a softwarefeature 🤔 https://github.com/gradle/gradle/pull/34628 and mostly https://github.com/gradle/gradle-client/pull/42

[hfhbd]

builder.bindSoftwareFeature("sqlDelight", bindingToTargetBuildModel(SqlDelight.class, KotlinMultiplatformBuildModel.class),

[tapchicoma]

ah yeah - Gradle folks just recently added composability examples and I haven't yet played with it true

[hfhbd]

Yeah, but it is very interesting as a 3rd party plugin author 😅 like I said, the current jvm and mpp and android plugins are very complex. IMHO I would only want 1 kotlin plugin, the mpp plugin even for a jvm target to have the same dsl for all targets/modules. (I am aware of the single mpp target problem through)

[hfhbd]

If you have a build with many modules, some jvm only and some mpp modules, switching between all the different DSLs (and behaviors like maven publishing setup) is annoying.

[tapchicoma]

with DCL we are aiming to have only one DSL for Kotlin (both KMP and JVM only). Maybe the most substantial change from current KMP design is separating models for library project and apps projects (in general we are getting inspiration from what Amper does in their DSL)

[Javier]

@hfhbd I have found impossible to have a single convention plugin with Gradle DCL until some “configuration” Property/Provider is added as in the moment you want to conditionally apply a third party plugin depending on your DSL, you need to use afterEvaluate which is not only bad by itself, it can be directly incompatible with the third party plugins so being totally blocked. Indeed, Kotlin was failing to me when I tried to apply it in the afterEvaluate block if the condition of using it was enabled in my DSL, as you cannot just apply it directly in the function without afterEvaluate because you cannot get a Project instance in the extension to get the pluginManager.

[hfhbd]

AFAIK with DCL, you should always apply all plugins (even 3rd) and react to the configuration.

[Javier]

That blocks having a single convention plugin. You cannot apply Kotlin JVM and Android plugins at the same time.

Same with Kotlin Multiplatform and Kotlin JVM.

AFAIK, if you apply all plugins you don’t have a way to disable them when reacting if you don’t need them for the current build.

Having multiple convention plugins does not scale well IMO:

• Kotlin JVM
• Kotlin JVM with KSP
• Kotlin JVM with Apollo
• Kotlin JVM with Protobuf
• Kotlin JVM with KSP, with Apollo, and with Protobuf
• A really long etc.
The amount of convention plugins will scale in an absurdly way to just be really hard to know which one to apply, without even starting to think in having different DSL for each combination.

[hfhbd]

I agree with Android, that is special.
But KMP vs Kotlin/JVM => There will only be 1 plugin/softwarefeature

And what's wrong with always applying ksp, Apollo and protobuf? the tasks should be skipped/not created if a user does not configure them.

[Javier]

The overhead will be noticeable for sure, and that is in the best scenarios in which the plugins are created correctly (or even perfectly). Which is not always the real case.

Even perfect plugins will need to add a way to be disabled (which is indeed an issue, as there are no configurations properties, there is no way to disable registering tasks or configs conditionally in a good way).

For example my SemVer plugin is working by default, if a user wants to apply it only on modules that are going to be published, the user cannot disable it in DCL, so I as the author I need to add a way that even it being applied it can be disabled at a project level, and being the DSL not very convenient for this for the lack of configuration properties, so basically depending on gradle.properties for each project that want to disable it or something similar.

Too complex and too awful over just having a new Gradle phase that can be used to apply plugins conditionally and those plugins can use that phase to register conditionally any task or configuration.

Said that, without reaching a Fragment like lifecycle from Android 😂