Why does build-logic implement convention plugins manually as opposed to just specifying it using Kotlin DSL?

[thesohelshaikh]

I am guessing this has something to do with performance but am curious about exact motivations behind this decision.

As per the official docs, plugins are defined using gradle files.

Is this the recommended approach for all apps? This would require significant investment to learn to write plugins opposed to writing it in gradle files which we are already used to.

[SimonMarquis]

I am guessing this has something to do with performance but am curious about exact motivations behind this decision.

IIRC the performance was slightly worse with Kotlin vs Groovy, but the main motivation was probably to follow the trend of Kotlin Everywhere, especially now that Kotlin DSL is Now the Default for New Gradle Builds.

As per the official docs, plugins are defined using gradle files.

Yes, but these are just code samples:

In this sample, convention plugins are implemented as [precompiled script plugins](https://docs.gradle.org/current/userguide/custom_plugins.html#sec:precompiled_plugins) - this is the simplest way to start out as you can use one of Gradle’s DSLs directly to implement the build logic, just as if the plugin was a regular build script.

This would require significant investment to learn to write plugins opposed to writing it in gradle files which we are already used to.

I don't think this is necessarily true. Plugins in Kotlin just need to be declared as classes, implement the Plugin<Project> interface, and be registered in the gradlePlugin.plugins block. (Groovy does this implicitly)
Then you have access to pretty much the same things.
But I agree, we are loosing some nice-to-have syntactic sugar around accessors:

java { /*...*/ }

vs

extensions.configure<JavaPluginExtension> { /*...*/ }

But at the same time, you can leverage Kotlin language features that are not available in Groovy.

[thesohelshaikh]

Got it, I completely agree with all of this. I do still have concerns about writing actual plugin vs writing DSL that gets converted to plugins. Again both of them being in Kotlin. Taking an example from repo:

extensions.configure<LibraryExtension> {
        ....
        defaultConfig.targetSdk = 34
        ....
}

vs

defaultConfig {
        ....
        targetSdk = 34 
        ....
}

Both of them are written in Kotlin but the second one is much simpler and what most developers are used to. If you have build files already using build.gradle.kts then you could just copy past the code and it should work out of the box. The only downside which I can think of is the DSL has to be converted into a plugin which might have some perf loss but am curious as to how much are we gaining in performance and it is really worth it to learn to write plugins. If we use DSL then there are a lot less chances to make mistakes as well.

[SimonMarquis]

To be honest, I never had the opportunity to write precompiled plugins with Kotlin script.
I'm not even sure if the IDE has the same level of support. For example, autocompletion, calling extension functions defined it other classes, defining (and extending) asbstract Plugins, etc.

[thesohelshaikh]

Understood, it has same level of IDE support we get when writing build files for modules in Kotlin script. Plus the added advantage here is you can just move the configuration defined in other modules to included build. There is not new syntax to learn.

[alexvanyo]

#38 was the PR that switched over, at that point in time there definitely was a noticeable speed improvement in the switch. I believe there has been speed improvements made more recently, but I don't think anyone has measured those improvements on this repo.

I do agree that if they were defined in .gradle.kts format, it keeps the syntax more "normal" as compared to when they are defined in .kt files like they are now.