Any good resources on how to migrate from Groovy G...

# gradle

[tylerwilson]

Any good resources on how to migrate from Groovy Gradle scripts to Kotlin DSL Gradle scripts? How about a converter that auto-converts to Kotlin, like we can with Java source pasted into Kotlin file. 🙂

[mbonnin]

I think an automatic converter is way harder due to the dynamic nature of groovy

[mbonnin]

I wrote this script https://github.com/martinbonnin/ktsify that automates "some" part of the process. But there's still a lot of manual tweaking to do

[tylerwilson]

Cool, I will take a look. Even a little cookbook style page would be nice. This in Groovy looks like this in Kotlin kind of thing.

[tylerwilson]

Like the cheat sheet you have on your page. Nice.

[mbonnin]

The good thing is that writing groovy Kotlin helps understanding a lot of the groovy internal structures like NamedDomainObjectContainer

[tylerwilson]

Though looking at that, it doesn’t look like Kotlin is an improvement - at least in number of characters you have to type…

[mbonnin]

It's more characters although you don't have to type them. With Kotlin, the IDE does this for you 🙂

[Andrzej]

There is an official guide: https://guides.gradle.org/migrating-build-logic-from-groovy-to-kotlin/

[nwillc]

I switch over to the Kotlin DSL across the board and never looked back. Once you get the feel of it, i.e. not just porting our build scripts, but authoring in Kotlin, they will be more concise, but the biggest win I feel is not having to remember “how do you do x in Groovy”. Things become more clean and consistent

[tylerwilson]

I hope so. I have said it elsewhere, but I think the fact that half the gradle scripts you find are groovy and many others are kotlin just make it harder to understand. And also, all the JetBrains IDEs gradle templates should be using one or the other…

[nwillc]

@tylerwilson That’s a bigger issue really. You can’t avoid the Groovy legacy of information - you’ll still constantly come across older information that’s groovy specific. Also, groovy, not being type safe, allowed for some pretty mysterious and sloppy solutions. You will definitely hit groovy examples where you have to actually go into the code to find the types etc needed to do equivalent in Kotlin.

[dwursteisen]

There is a guide about the migration: https://guides.gradle.org/migrating-build-logic-from-groovy-to-kotlin/

[dwursteisen]

For your information, a lot of example are now in Groovy and in Kotlin in the Gradle documentation.

[Brendan Weinstein]

I switched to kotlin dsl with the motivation that most of multiplatform open source projects were using gradle dsl, so it was easier to follow along.

Now when I dig up tutorials on annotation processors I am cursed with figuring out what the gradle dsl equivalent is for github samples still on groovy.

In the long-run gradle dsl is great imo; it makes me feel better about how efficient I can be customizing buildscripts.

The lack of documentation for the android plugin is annoying. And the fact that everyone hasn't made the jump quickly means that we're all screwed on referencing code online, whether you stayed on groovy or switched to kotlin dsl.

[jk2018]

There's also this: (https://github.com/bernaferrari/GradleKotlinConverter ) Have not used the tool ( found it a bit too late in the process ), but there's an even longer "cheat sheet" at the bottom of the README which helped me.

[jk2018]

One other strategy I've used ( and it may be obvious): Search for whatever you want to convert in github and limit the file name to "build.gradle.kts"

[jk2018]

I'm a bit surprised how little official docs or samples there are for this.

[mbonnin]

https://github.com/bernaferrari/GradleKotlinConverter is brilliant by the way, I linked it in my repo, it's much more capable than ktsify

[napperley]

Strongly recommend that the OP learns the basics of Gradle first. This video tutorial looks like a good starting point (covers Kotlin, and Groovy DSL's):

https://youtu.be/I4HICQ-KoV4▾

[gildor]

Already mentioned official migration guide is very good, but don't forget about official documentation of Kotlin DSL, it has also overall overview of API and explains how Kotlin DSL works, it also very useful information
https://docs.gradle.org/current/userguide/kotlin_dsl.html

[mbonnin]

@gildor I actually think a lot of users want "Kotlin build scripts" mainly, not "Kotlin DSL". "Kotlin DSL", with generated accessors, HasImplicitReceiver, etc is a bonus but can also be confusing and look magic at first

[gildor]

Not sure what is "Kotlin build script"

[mbonnin]

"Kotlin build script" is just writing your build.gradle.kts in Kotlin. Without generated accessors, implicit receivers or kotlin-dsl plugin. None of that is actually needed to write gradle files in Kotlin.

[gildor]

But why?How will it work with existing plugins?

[mbonnin]

Just access their Extension , I usually just do configure<BaseExtension> {} instead of android {} for the Android Plugin for an exemple

[gildor]

You don't need kotlin-dsl explicitly to write build.gradle.kts

[gildor]

But why?

[gildor]

Anyway, you can do this, but it's definitely not what most of users want

[mbonnin]

Ok, it's anectotal evidence based on only myself then 🙂. Some time ago, the generated accessors weren't working super well in IntelliJ and not relying on them made the IDE smoother. Also, it forces to think into actual Gradle APIs that are documented in javadoc and easily discoverable with Ctrl + click.

[mbonnin]

Relying on generated accessors is nice until you realize that the below doesn't work in Kotlin:

android {
    signingConfigs {
         release {
            // some stuff
         }
    }
}

And then you have to look into NamedDomainObjectContainer , call create("release") etc... so might as well do it from the beginning

[gildor]

I mean for sure, bad tooling is huge problem of Kotlin DSL, but without accessors it's incredible tedious to write Kotlin DSL build scripts and it's big disadvantage comparing to Groovy, and as adopter of it from version 0.1 I remember how terrible it was

I think use Gradle API and Plugin API directly instead of designed DSL for it really bad idea for final user

[gildor]

Yes, this example is perfect case when Kotlin DSL is actually good and do not hide those terrible implicit apis of Groovy, and such case is fine if plugin has Kotlin DSL example

[mbonnin]

Yea, the implicit stuff always got me confused, I never know what I'm manipulating.

[mbonnin]

Anyways, my main gripe right now is the kotlin-dsl plugin I guess that I haven't had the time to completely investigate. Putting that on the migration path feels a bit like too much information