I understand they didn't want to use the same DSL ...

# gradle

[breandan]

I understand they didn't want to use the same DSL in Kotlin as Groovy, but there's a bunch of extra ceremony for using the Kotlin DSL right now

[gildor]

They actually want to use the same DSL

[gildor]

In you case yeah, this plugin uses deprecated approach and not friendly to Kotlin DSL and make sense to create an issue for plugin author
Guys from JB can fix it

[breandan]

I mean, it's not just this plugin. Plugin authors everywhere will now have to support two different front ends. I would have expected the RC to be more polished. Last I heard they were redesigning some aspects of the DSL, but maintaining the overall structure http://talkingkotlin.com/gradle-script-kotlin-with-rodrigo-oliveira/. But it seems like the API for plugins will require a lot of work on the plugin authors to support two different DSLs...

[gildor]

Plugin authors everywhere will now have to support two different front ends

No need to support two. Plugin author just should follow Gradle recommendation for plugins and such plugin will work proprly for Groovy and Kotlin

[gildor]

ExtensionAware and other dynamic approaches are not recommended

[gildor]

But I agree, this is problem of Gradle to be too dynamic, especially on early days, so we have problems with too dynamic pluggins

[gildor]

I would have expected the RC to be more polished

Unfortunately Kotlin DSL can do nothing with dynamic plugins, the way that they follow is to fix existing Gradle APIs and popular plugins

[gildor]

I heard they were redesigning some aspects of the DSL

Exactly, implementation is different, type safe, not like dynamic grovvy, but still they try to have the same (source-compatible as it possible) DSL

[breandan]

Even plugins which conform the the Gradle best practices have slightly different DSLs, e.g. https://github.com/duckietown/hatchery/blob/master/build.gradle.kts#L186:L196 (assignment becomes function invocation) Seems like it should have been possible for end users to stay closer to the Groovy usage for plugin configuration

[gildor]

yes, sure, it’s impossible to have completely the same code on Kotlin, Groovy syntax allows some things that not possible in Kotlin, can be fixed by plugin author in some cases, or just provide an example

[gildor]

there is a big epic task about docs for third-party plugins
https://github.com/gradle/gradle/issues/6790

[breandan]

I see, thanks for the link

[gildor]

but again, I completely understand your concerns, there are migration problems, especially with some plugins
Best what community can do in this case it ask plugin authors to fix it, also some new Kotlin features can help in some cases, such as setters overloading or property setters of different types to have DSL closer to Groovy

[breandan]

Yes, that would be very helpful. I've noticed it is often not possible to write to a property with the property = syntax, even though a setProperty method is provided (similar to Java interop)

[gildor]

on KotlinConf I also talked with Kotlin Team guys about fixing of their plugins DSL, to be more pleasant to use from Groovy and Kotlin
There are just a lot of bad practices common in many plugins that not so critical if you use them from Groovy (when you write magical code and even don’t know what is that, task, extensions, method invocation or convention) and from Kotlin, where you need type safe API

Gradle API is still too dynamic sometimes, hope that future evolution of Gradle will be about moving to more static APIs in core and preventing usage of dynamic API when it’s possible, so make Kotlin DSL usage more “kotlin-ish” and easy

[gildor]

property = syntax, even though a setProperty method is provided (similar to Java interop)

Yeah, usually because getProperty is not avilable or getProperty and setPropery have different types or even nullability

[breandan]

I see. Makes sense

[napperley]

More Kotlinic (idiomatic Kotlin/aka the Kotlin way) Gradle APIs would be a big boon.

[breandan]

At least for plugin configuration, it would be nice if that DSL was syntactically as close to the Groovy DSL as possible. Not sure how achievable that is, but the fewer characters that need to be changed, the easier it will be for people to migrate. In the ideal scenario, there would be an inspection that could programmatically transform Groovy to Kotlin DSL like Java to Kotlin. Maintaining two sets of documentation or requiring plugins authors to add a bunch of extension methods is just not going to scale well

[gildor]

requiring plugins authors to add a bunch of extension methods is just not going to scale well

this is not a solution. Solution to provide DSL implementation that works same or very similar for both Groovy and Kotlin, for many use cases it’s already true if follow some rules

[gildor]

programmatically transform Groovy to Kotlin DSL like Java to Kotlin

Unfortunately it’s almost impossible. Groovy is too dynamic so you cannot write proper tooling for it (this is main reason why Gradle decide to use Kotlin). Of course it can be some very simple and dump converter (replace string ' to ", replace a few known dsls, but it really not scalable solution)

[gildor]

it would be nice if that DSL was syntactically as close to the Groovy DSL as possible

This is achievable in many cases, especially if plugin author worry about it, but still many ways to break this source compatibility