In case you wanted to use Gradle+Kotlin in your *Android *build, but you were blocked by the Android team doing absolutely nothing to make it happen (except showing a popup to say that there are not supporting it) here is a nice work-around: - Extract the

android { ... }

block to a separate file

app/android.gradle

- Convert the rest of

app/build.gradle

to

app/build.gradle.kts

- Add in `app/build.gradle.kts`:

apply(from = "android.gradle")

Example here: https://github.com/jmfayard/update-legacy-android-project/commit/a22c3c4cad4f8db7d562bf7313e23f21b7f7c0d4

What exactly doesn’t work? I’m using kts files everywhere and didn’t encounter any problem

For example it's not published on the gradlePluginPortal so we have to use the old, bad, legacy

buildscript { ... }

syntax https://plugins.gradle.org/search?term=com.android.application

I’m not using the

buildScript

block in any of my Gradle files in any project

Interesting. But they still have no documentation anywhere about how to use their plugin with Kotlin. I find it puzzling given that - Android Studio support for editing build.gradle files is bad now, has been bad since years and will never b e good - IntelliJ and Gradle support for editing build.gradle.kts files is ok-ish now, and will get better in the future (performance-related improvments to come in 1.3.60) - Most Android developers now know Kotlin, few know Groovy

I'm doing the pluginManagement thing as well. The android plugin is not super well documented but as far as the plugin portal is concerned, I find gradle to put an additional burden on the plugin developers.

@mbonnin For users, it allows to install a Gradle plugin in a declarative way in one line without having to care about the orders For example: https://plugins.gradle.org/plugin/de.fayard.refreshVersions For IDE support, it allows the Kotlin DSL to know which methods are available for you. From an author perspective, I don't find it complicated from a

./gradlew :publishPlugins

and that's it. Here is what my configuration looks like https://github.com/jmfayard/buildSrcVersions/blob/ec3880ce72f736f30bb6c7bed413c9b67a28e84f/plugin/build.gradle.kts#L3-L33

That's one more place to publish (and maintain credentials) and I don't really see why this is needed for declarative + order independent + autocomplete. All theses feature should reasonnably be doable fetching the artifacts from mavenCentral or jcenter no ?

Well I have never published to mavenCentral but I did on the gradlePluginPortal, so I guess that whatever we are used to feel easier @mbonnin 🙂

True but mavenCentral/jcenter: 1. also host runtime jars (which a lot of plugins also require) 2. doesn't require a markerId 3. is I feel more widely used

@mbonnin About credentials: you can connect to Gradle portal using GitHub credentials, which you already have if your project is hosted there.

I’d like to clear a few misconceptions - “blocked by the Android team doing absolutely nothing to make it happen” You are not blocked using Gradle kotlin DSL in Android studio or in any Android project for that matter by the Android team. Its just a Gradle thing that if the plugin is not published to the plugin portal (with that weird af artifact name) then you have to supply the repositories and/or module artifact that contains the plugin classes. - Newer versions of IJ and AS plus the kotlin and gradle plugins provide much better support for editing build.gradle.kts files. I haven’t noticed any issues since I switched fully to kotlin DSL. - As far as working with AGP, almost nothing has changed except the lack of Groovy dynamism and the syntax. AGP will still contribute the same classes and methods. I recommend reading the kotlin dsl primer first to get a feel for the differences b/w both (https://docs.gradle.org/current/userguide/kotlin_dsl.html). How-tos are still lacking but that is true even currently for Groovy, e.g. highest rated search for how to do <anything> in AGP is usually a stackoverflow or some blog post. - Yes the plugin portal allows users to install plugins by id without extra declaration but it doesn’t “allow the Kotlin DSL to know which methods are available for you.“. That is by virtue of declaring plugins via the

plugins {...}

block. Overall, I wouldn’t recommend extracting your

android {...}

block to a groovy script file and apply. I would stick to using the

pluginManagement {...}

block in settings or (my personal fave) declaring the module artifacts as

buildSrc

dependencies (effectively making them build script dependencies too). That way you can use the android plugin via

plugins {...}

and it works without issues.

@efemoney thanks for your message. I agree with you on the

pluginManagement {...}

block. Please note that it is not a mis-conception but the sad state of things that the Android Gradle Plugin does not currently have Kotlin snippets for documentation. As you can see in this ticket, it's pretty unique among popular Gradle plugins for this matter. https://github.com/gradle/gradle/issues/6790 And it's especially infuriating for a number of reasons: 1) AGP is especially complex 2) Lots of Android developers know Android 3) Android Studio is a terrible IDE when the Sync fails That is the reason for the

app/android.gradle

pattern.

Yes, the misconception is that working with Kotlin DSL vs Groovy for AGP is vastly different and somehow dependent on AGP authors releasing how to guides. Its not.

Agree with you, I was not concerned about theoritical difference, but about the practical aspects. If an Android developer just starts with the Kotlin DSL and has no documentation to rely on, it's not a nice experience

Yes, you’re right that it is a significant pain point in practice.

Also note that using the plugins block works with plugins from repositories other than the plugin portal. The mechanics aren’t about the plugin portal but about published metadata. See https://issuetracker.google.com/issues/64551265 (and upvote 😉 ) about changing the AGP publication to the Google repository to include the required metadata.

thanks for the info!

build.gradle.kts

has just landed in AS 4.0 🙌

correct, but that's super easy

// settings.gradle.kts
pluginManagement {
    repositories {
        google()
        jcenter()
        gradlePluginPortal()
    }
}

Easy when you know it's possible. It's not that easily discoverable. I would have put everything in the plugin block:

plugins {
    repositories {
        google()
        jcenter()
        gradlePluginPortal()
    }
    id ("com.android.application) {
        artifact("com.android.tools.build:gradle:3.5.0")
        apply(false)
    }
}

But maybe there's some classpath isolation/class loading constraint I'm missing

build.gradle.kts

has just landed in AS 4.0

what does that mean exactly since the issue is not marked as resolved? https://issuetracker.google.com/issues/64551265

Means there's a small window in AS that says it's working now 😅

I asked in the Android Studygroup slack channel in case you are there as well https://androidstudygroup.slack.com/archives/C03KKLGC2/p1571865244316300

I guess .kts samples will follow. TBH, most of the differences I have seen are replacing simple quotes with double quotes and spaces by regular function calls

I don't find it easy at all to get started right now, so there is still work to do from their side. And documentation is super important

But it's mostly syntax that is changing, logic stays the same. Actually, I find having autocomplete makes things easier

it's possible, but it shouldn't be 10 times harder than on my backend project in IntelliJ that works like a charm, it consists in a single

build.gradle.kts

with like 50 lines

My ahah moment was to realize that

android {}

was

extensions.getByType(BaseExtension::class.java).apply {}

which can be simplified to just

configure<BaseExtension> { .. }

Nice!

To compare the experience on the backend with IntelliJ Go to https://start.spring.io/ Choose Project=Gradle Language=Kotlin Explore with Ctrl-space See the nice

build.gradle.kts

Generate with Cmd-Enter Open in IntellliJ Works like a charm @mbonnin

Right, AS 4.0 should make

build.gradle.kts

by default

Well they should fix their bugs and documentation first. Let see if they reply to my comment on androidstudygroup

I'm very late to the party: - I use the pluginManagement or at some projects add it to the classpath at buildscript, but with both approaches I can use the plugins block & build.gradle.kts - I publish my plugins to our Artifactory and consume them from it using plugins block ( with the markers, yes, but as I use the Kotlin-dsl plugin they are generated automatically and I don't care )