In case you wanted to use Gradle+Kotlin in your *A...

# gradle

[jmfayard]

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

[ribesg]

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

[jmfayard]

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

[jmfayard]

For example unless most popular Gradle plugins,
the Android team did not bother to provide Kotlin DSL usage samples
https://github.com/gradle/gradle/issues/6790

[jmfayard]

I'm not sure even they know and care that Android Studio's support for editing build.gradle files is bad

[ribesg]

I’m not using the buildScript block in any of my Gradle files in any project

[ribesg]

You just need to setup pluginManagement in your settings file

[ribesg]

(Which you should do anyway because a lot of things aren’t on the plugin portal, so from time to time you just add those 2 lines to your pluginManagement setup for a plugin)

[jmfayard]

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

[mbonnin]

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]

It adds a markerId in addition to pluginId and artifactId adding some confusion and I'm not sure what the benefit is

[jmfayard]

@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

[mbonnin]

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 ?

[jmfayard]

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 🙂

[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]

I wouldn't mind if mavenCentral plugins would be treated the same as the gradlePortal ones but right now, the distinction looks artificial

[louiscad]

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

[efemoney]

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.

[jmfayard]

@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.

[efemoney]

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.

[efemoney]

The differences are more fundamental to Gradle. syntax and lack of dynamism (hence reliance on code generated accessors etc)

[jmfayard]

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

[efemoney]

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

[eskatos]

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.

[jmfayard]

thanks for the info!

[mbonnin]

build.gradle.kts has just landed in AS 4.0 🙌

[mbonnin]

@eskatos even if the metadata (= marker artifact?) is published, we still need to tell gradle what repo to search no ? By default only the plugin portal is searched, maybe mavenCentral but I'm almost sure jcenter/google is not in there

[jmfayard]

correct, but that's super easy

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

[mbonnin]

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

[jmfayard]

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

[mbonnin]

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

[mbonnin]

Actually, I've been using them for some time in AS 3.5.1 so not sure what was broken before. Indexing after/while changing the files was sometimes a bit long, maybe it's just that

[mbonnin]

Ah, I just clicked the issue. It's not related to the publication of the android gradle plugin. More to the Android Studio support of syntax highlight, etc.. for build.gradle.kts files

[jmfayard]

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

[mbonnin]

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

[mbonnin]

Then for the more complex stuff, everything went smoothly once I stop trying to use the generated accessors 😅

[jmfayard]

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

[mbonnin]

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

[mbonnin]

You don't even have to use the plugin {} syntax if you don't use the generated accessors, you can keep the old buildscript

[jmfayard]

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

[mbonnin]

My ahah moment was to realize that android {} was extensions.getByType(BaseExtension::class.java).apply {}

[eskatos]

which can be simplified to just configure<BaseExtension> { .. }

[mbonnin]

Nice!

[jmfayard]

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

[mbonnin]

Right, AS 4.0 should make build.gradle.kts by default

[mbonnin]

(which it does not at the moment)

[jmfayard]

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

[cristiangm]

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 )