Is it possible to write tasks in Kotlin in buildSr...

# gradle

[ghedeon]

Is it possible to write tasks in Kotlin in buildSrc, without migrating to DSL?

[mbonnin]

Yes, it should work fine.

[ghedeon]

hm. It's highlighted, but it stops working after I convert it to Kotlin.

Ex: Java

package com.foo;

public class Fun {
  public static void sayHello() {
    System.out.println("Hello");
  }
}

Usage:

task hello {
    doLast {
        com.foo.Fun.sayHello()
    }
}

That works. Once I convert Fun to kotlin it can't import it anymore.

[mbonnin]

Did you configure kotlin in buildSrc/build.gradle ?

[ghedeon]

yes, like this:

plugins {
    kotlin("jvm") version '1.3.31'
}

dependencies {
    implementation gradleApi()
    compile(kotlin("stdlib-jdk8"))
}

[gildor]

You don't need Kotlin Plugin, it already bundled to Gradle, but you may use kotlin-dsl plugin which configures gradleApi, stdlib and uses bundled versions of it:

plugins {
   id "org.gradle.kotlin.kotlin-dsl" version "1.2.10"
}

[gildor]

Check that your import is correct (maybe you need something like com.too.FunKt or Companion, depends on how your final code looks like), check that this file in buildSrc/src/kotlin, not in src/groovy

[kingsley]

Also, might be possible that you’re missing @JvmStatic on that method, so the Groovy buildscript doesn’t see it as a static Fun.sayHello() anymore

[gildor]

yes, it depends what is final kotlin code

[ghedeon]

@gildor you mean to mirgate buildSrc to kotlin-dsl? Or just applying the dsl plugin in build.gradle? Because the later gives me NoClassDefFoundError: org/gradle/kotlin/dsl/support/KotlinDslPluginsKt

[gildor]

Just apply Kotlin DSL plugin to buildSrc project

[gildor]

Anyway, it's not requirement, just simplifies configuration and provide a lot of Kotlin DSL helpers for work with Gradle API from kotlin

[gildor]

Looks that this version of Kotlin DSL not compatible with your gardle version, unfortunately there is no easy way to consume this plugin to match Gradle, you can check requires Kotlin DSL version in your Gradle distribution sources, but don't remember how to do that exactly. Because if you use kotlin-dsl for build.gradle, you have convinient accessor for this plugin. I created an issue about it, to simplify usage of kotlin-dsl plugin from Groovy code, but it's not fixed, as I remember

[ghedeon]

well, didn't work, as I mentioned the error. Even without going dsl path, let's take a simple case:
/buildSrc/src/main/kotlin/Dependencies.kt

object deps {
    val multidex = "androidx.multidex:multidex:2.0.1"
}

I expect this to be visible in any of my build.gradle files as implementation deps.multidex. But it's not...

[louiscad]

@ghedeon Which Android Studio version are you using?
FYI, 3.3 and 3.4 broke buildSrc referencing from groovy based build.gradle scripts, but it is fixed in 3.5 now in RC. (That bug kicked-off my migration to Gradle Kotlin DSL)

[ghedeon]

AS 3.4.2 😬

[louiscad]

Then, install 3.5 RC3 aside, and open the project with it (no need to update AGP)

[ghedeon]

just did it. Still doesn't work but at least I've got imports recognized by IDE. So, clicking on deps.foo actually brings you to your kotlin file in buildSrc. I'm wondering what people that answered "YES" do...

[louiscad]

They replied regarding theory, but at least two of them are using Gradle Kotlin DSL and dropped dynamic syntax.

[mbonnin]

@ghedeon an example of using a kotlin buildSrc with build.gradle files: https://github.com/HearthSim/Arcane-Tracker/tree/bdf01d728d5eddefba68f76e5da155620f480d00/buildSrc

[mbonnin]

The buildSrc kotlin plugin is imported from app/build.gradle there https://github.com/HearthSim/Arcane-Tracker/blob/bdf01d728d5eddefba68f76e5da155620f480d00/app/build.gradle#L1

[gildor]

I expect this to be visible in any of my build.gradle files as implementation deps.multidex. But it's not...

Why do you expect that it will work? Groovy is not Kotlin, you have to use Java syntax, something like:
deps.INSTANCE.getMultidex(), or use JvmStatic instead

[mbonnin]

Or make multidex const ?

[mbonnin]

I have this,

object Libs {
    const val supportLibVersion = "28.0.0"
}

Kotlin bytecode shows:

public final class Libs {


  // access flags 0x19
  public final static Ljava/lang/String; supportLibVersion = "28.0.0"
  @Lorg/jetbrains/annotations/NotNull;() // invisible

[gildor]

yeah, you right! It will work with object

[ghedeon]

@gildor Irrelevant. Groovy recognizes that, even without const

[gildor]

recognize Kotlin Object?

[ghedeon]

yes

[gildor]

what doesn’t work than in your case?

[ghedeon]

well, you won't belive me... but apparently lower case name of the class

[ghedeon]

motherfucking flying bag of dicks. 2 days. object deps --> object Deps

[gildor]

maybe just some name conflict?

[gildor]

What kind error did you have?

[ghedeon]

same for Libs and libs

[gildor]

what abou SomethingRandom and somethingrandom? %)

[ghedeon]

that deps does't exists

[gildor]

Groovy 🤷‍♂️

[ghedeon]

same for somethingrandom. They are for real

[ghedeon]

if it's not ridiculous enough, in my side project with kotlin dsl lower case is not a problem. So, it's just this weird combination of groovy and kotlin

[ghedeon]

was nice knowing you guys, for all these years. I think I give up on android. 👋

[gildor]

Not really related on Android tho 😬

[ghedeon]

disagree. It's an essential part of the android development. They brought gradle to android in 2013-2014? 5 years later terrible support in IDE, constant breaking changes, incompatibilities, performance issues, etc. It's an everyday struggle.

[louiscad]

If you use gradle the default simple way, with no third-party plugins, it just works.

[louiscad]

You're putting code into the build script itself. Understandable Google folks didn't expect this at first. Kotlin wasn't still in early, early stages, mostly unknown.

[gildor]

It’s an essential part of the android development

Yeah, same as huge amount of other technologies, and at least Gradle can be avoided if you really know what are you doing