CODEWITHSUNDEEP
androidgradlekotlin-script
user1933677
user1933677

Reputation:

How to translate some old gradle code to new Kotlin script gradle (.kts)

I'm trying to follow this sparse and vague tutorial for using pocketsphinx-android in Android. I'm having trouble with the "including resource files" section. It wants me to put the following in my app/build.gradle ..

ant.importBuild 'assets.xml'
preBuild.dependsOn(list, checksum)
clean.dependsOn(clean_assets)

.. but it doesn't work as I'm pretty sure it isn't Kotlin script which my gradle, app/build.gradle.kts, needs.

So far, I've gotten my app to sync and build (without this gradle code) but when runs it complains it can't access assets.lst so I think this is my last hurdle.

Can someone translate this code for me? Or is there a way to include old gradle code in the new gradle?

Upvotes: 0

Views: 104

Answers (1)

Simon Jacobs
Simon Jacobs

Reputation: 6663

Well there is a Groovy to Kotlin migration guide out there.

Here are three rules that apply to your snippet:

  1. Quotes. Kotlin uses double quotes for strings, whereas Groovy can use single or double quotes.

  2. Braces. Groovy can call any single-argument function without braces; such function calls do exist in Kotlin, but only for appropriately defined functions, and such functions are not so common in Gradle scripts1.

  3. Task name variables. In Groovy you can refer to a task that has already been defined by its name in the root of the build script. In Kotlin a similar syntax is possible, but only within the tasks block and only when such a task was defined in a plugin that has been applied in the plugins block.

    Even then, the Kotlin accessor gives you a TaskProvider rather than a Task, meaning you will have to call configure on them to configure them. Such TaskProvider objects are valid as arguments to dependsOn though.

Applying these rules makes your three lines become:

tasks {
    ant.configure { importBuild("assets.xml") }
    preBuild.configure { dependsOn(list, checksum) }
    clean.configure { dependsOn(clean_assets) }
}

This assumes that all the above tasks were defined in a plugin; otherwise you will have to access them with eg named("clean_assets") instead2.

1 One example I can think of it specifying the version of a plugin eg

plugins {
    kotlin("jvm") version "1.9.23"
}

Here version is such a function.

2 named also accepts a closure as a second argument which configures the associated task, so that can be used instead of a separate configure call, should configuration be the aim of the call

Upvotes: 0

Related Questions