Gradle KTS — was ist das, Kotlin DSL für Gradle und Syntax

Was ist Gradle KTS?

Gradle KTS ist ein Kotlin-DSL (Domain Specific Language), das eine Alternative zu Groovy zum Schreiben von Gradle-Konfigurationsdateien bietet. Anstelle der Groovy-Syntax verwenden Entwickler Kotlin — eine streng typisierte Sprache, die die Korrektheit der Konfiguration zur Kompilierzeit überprüft. KTS wurde erstmals 2018 in Gradle 5.0 als experimentelle Funktion eingeführt und erreichte in Gradle 6.0 Stabilität.

Das Hauptziel von KTS ist es, die Nachteile von Groovy in Build-Skripten zu beseitigen. Groovy ist eine dynamisch typisierte Sprache, bei der Konfigurationsfehler erst zur Laufzeit bei der Ausführung einer Aufgabe auftreten. KTS ermöglicht es, dieselben Fehler bereits in der Codebearbeitungsphase dank der statischen Typisierung von Kotlin zu erkennen. Darüber hinaus bietet KTS Zugriff auf die Gradle-API mit vollständiger Typdokumentation, was das Erlernen und Verwenden komplexer Konfigurationsblöcke erheblich vereinfacht.

Das KTS-Ökosystem wird von allen wichtigen Tools unterstützt: Android Studio, IntelliJ IDEA, VS Code mit dem Kotlin-Plugin und dem Gradle Build Tool. Alle modernen Plugins (Android Gradle Plugin, Kotlin Multiplatform, Protobuf, Compose) bieten eine Kotlin-freundliche API mit expliziten Typen, was KTS zur bevorzugten Wahl für neue Projekte macht.

Wie Gradle KTS funktioniert

Gradle KTS verwendet den Kotlin-Compiler zur Verarbeitung von .gradle.kts-Dateien. Gradle erkennt die Erweiterung und übergibt die Skripte an die Kotlin-Scripting-Engine, die sie in Klassen kompiliert. Diese Klassen werden dann von Gradle ausgeführt, um das Projektmodell zu erstellen. Der Hauptunterschied zu Groovy: KTS-Skripte werden vorab kompiliert und nicht dynamisch interpretiert, sodass Fehler erkannt werden können, bevor die Aufgabenausführung beginnt.

Die KTS-Architektur basiert auf kotlin-scripting. Jede .gradle.kts-Datei ist ein Kotlin-Skript mit impliziten Importen der Gradle-API. Der Entwickler kann beliebige Kotlin-Konstrukte verwenden: Erweiterungsfunktionen, Lambdas, Datenklassen und sogar Hilfsfunktionen innerhalb des Build-Skripts deklarieren. Gradle stellt eine Reihe von Erweiterungsfunktionen für die typisierte Konfiguration von Blöcken bereit: dependencies, android, kotlin und andere.

plugins {
    id("com.android.application") version "8.4.0"
    kotlin("android") version "2.0.21"
}

android {
    namespace = "com.itsectr.app"
    compileSdk = 34

    defaultConfig {
        applicationId = "com.itsectr.app"
        minSdk = 26
        targetSdk = 34
        versionCode = 1
        versionName = "1.0.0"
    }
}

dependencies {
    implementation(platform("androidx.compose:compose-bom:2024.06.00"))
    implementation("androidx.compose.ui:ui")
    implementation("androidx.core:core-ktx:1.13.1")
}

Typkonvertierung in KTS

Einer der Hauptunterschiede zwischen KTS und Groovy ist die Typbehandlung. In Groovy akzeptieren alle Konfigurationen Object, während sie in KTS spezifische Kotlin-Typen akzeptieren. Beispielsweise akzeptiert compileSdk Int, keinen String. Dadurch werden Fehler im Zusammenhang mit falschen Typen vermieden: In Groovy funktionieren compileSdk 34 und compileSdk "34" identisch, während in KTS nur die erste Variante gültig ist. Diese Strenge macht die Konfiguration vorhersehbarer und dokumentierter.

Gradle KTS vs Groovy: Vergleich

Groovy war das ursprüngliche DSL für Gradle und wird weiterhin voll unterstützt. KTS bietet jedoch mehrere Vorteile, die es zur empfohlenen Wahl für neue Projekte machen. Statische Typisierung, bessere Bearbeitungsleistung in der IDE und strengere Syntax sind die Hauptgründe für den Wechsel zu KTS. Gleichzeitig behält Groovy seinen Vorteil bei der Übersichtlichkeit für einfache Konfigurationen.

Die Build-Leistung bei KTS und Groovy ist nach der Skriptkompilierung nahezu identisch. KTS-Skripte benötigen beim ersten Start oder nach dem Leeren des Caches länger zum Kompilieren, aber nachfolgende Builds laufen mit derselben Geschwindigkeit wie Groovy-Skripte. Gradle speichert kompilierte KTS-Skripte im Build-Verzeichnis zwischen, sodass eine Neukompilierung nur bei Änderung des Skripts erfolgt.

Die Wahl zwischen KTS und Groovy im Jahr 2026 ist klar: Für neue Projekte — KTS. Google, JetBrains und Gradle empfehlen KTS für alle neuen Projekte. Groovy bleibt für die Wartung von Legacy-Projekten relevant, bei denen eine Migration aufgrund des Konfigurationsumfangs oder spezifischer, mit KTS nicht kompatibler Plugins unpraktisch ist.

Codebeispiele: Build-Skripte in KTS

Betrachten wir typische Konfigurationsblöcke in KTS für Android, Kotlin Multiplatform und Compose Multiplatform. Ein Android-Projekt mit KTS erfordert explizite Typangaben in der Konfiguration von buildTypes und productFlavors. Das folgende Beispiel zeigt die Einrichtung einer Anwendung mit zwei Varianten.

android {
    buildTypes {
        val release = getByName("release") {
            isMinifyEnabled = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
        getByName("debug") {
            applicationIdSuffix = ".debug"
        }
    }

    flavorDimensions += "version"
    productFlavors {
        register("demo") {
            dimension = "version"
            versionNameSuffix = "-demo"
        }
        register("full") {
            dimension = "version"
        }
    }
}

Für Kotlin Multiplatform ist KTS obligatorisch — Groovy unterstützt die Konfiguration von Multiplattform-Modulen nicht korrekt. Die KMM-Modulkonfiguration umfasst das Einrichten von Zielplattformen und Source Sets. Das folgende Beispiel zeigt die Konfiguration des Shared-Moduls mit iOS und Android.

kotlin {
    androidTarget {
        compilations.all {
            kotlinOptions {
                jvmTarget = "17"
            }
        }
    }

    listOf(
        iosX64(),
        iosArm64(),
        iosSimulatorArm64()
    ).forEach { iosTarget ->
        iosTarget.binaries.framework {
            baseName = "Shared"
            isStatic = true
        }
    }

    sourceSets {
        commonMain.dependencies {
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.9.0")
        }
        androidMain.dependencies {
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-android:1.9.0")
        }
    }
}

Hilfsfunktionen und benutzerdefinierte Tasks

KTS ermöglicht das Deklarieren von Kotlin-Hilfsfunktionen innerhalb des Build-Skripts. Dies ist besonders praktisch für wiederkehrende Konfigurationen wie Signing Configs oder Versionsverwaltung. Dank der statischen Typisierung können solche Funktionen mit Parametervalidierung zur Kompilierzeit aufgerufen werden, wodurch Fehler in Signing-Konfigurationen vor der Veröffentlichung im Google Play Store vermieden werden.

fun Project.configureSigning() {
    android {
        signingConfigs {
            register("release") {
                storeFile = file("release.keystore")
                storePassword = System.getenv("KEYSTORE_PASSWORD")
                keyAlias = System.getenv("KEY_ALIAS")
                keyPassword = System.getenv("KEY_PASSWORD")
            }
        }
    }
}

// Verwendung in build.gradle.kts
configureSigning()

Migration von Groovy zu KTS

Die Migration von Groovy zu KTS ist ein Prozess, der schrittweise durchgeführt werden kann. Gradle unterstützt gemischte Projekte, bei denen einige Module Groovy (build.gradle) und andere KTS (build.gradle.kts) verwenden. Die settings.gradle und die root build.gradle können zuerst migriert werden, da sie nicht von den Modul-Plugins abhängen. Google empfiehlt, die Migration mit settings.gradle.kts zu beginnen, dann der root build.gradle.kts und erst dann den Modulen.

Die wichtigsten Migrationsschritte umfassen: Ersetzen der Closure-Syntax durch Lambdas, Hinzufügen von =-Zeichen für Zuweisungen, Ersetzen von String-Keys durch typisierte Konstanten und explizite Variablentypisierung. Android Studio bietet automatische Konvertierung von Groovy zu KTS für einfache Blöcke, aber komplexe Konfigurationen mit verschachtelten Closures erfordern manuelles Umschreiben.

Typische Migrationsprobleme umfassen implizite Groovy-Methodenaufrufe, die kein Kotlin-Äquivalent haben, und Plugins, die keine Kotlin-freundliche API bereitstellen. Für das erste Problem bietet Gradle Kompatibilität über withGroovyBuilder — einen Mechanismus, der es ermöglicht, Groovy-Methoden von KTS aus aufzurufen. Für das zweite Problem muss entweder auf ein Plugin-Update gewartet oder das Plugin bis zur vollständigen Migration in einem Groovy-Modul verwendet werden.

Gradle KTS für Kotlin Multiplatform

Kotlin Multiplatform ist das primäre Projekt, in dem KTS eine zwingende Anforderung ist. Das kotlin-multiplatform-Plugin bietet Erweiterungen zur Konfiguration von Zielplattformen, Source Sets und Framework-Binärdateien, die nur über das Kotlin-DSL verfügbar sind. Groovy unterstützt die Multiplattform-Konfiguration nicht korrekt, daher verwenden KMM-Projekte ausschließlich KTS.

Die KMM-Konfiguration in KTS umfasst nicht standardmäßige Blöcke: kotlin.target zur Angabe von Plattformen, kotlin.sourceSets zur Organisation von gemeinsamem und plattformspezifischem Code, kotlin.cocoapods zur Integration mit CocoaPods und kotlin.jvmToolchain zur JDK-Auswahl. Jeder Block verfügt über eine streng typisierte API mit Autovervollständigung in Android Studio, was besonders wertvoll für die komplexe Konfiguration von KMM-Projekten mit mehreren Plattformen ist.

kotlin {
    iosArm64()
    iosSimulatorArm64()
    iosX64()

    cocoapods {
        summary = "Shared Kotlin module"
        homepage = "https://itsectr.com"
        framework {
            baseName = "Shared"
            isStatic = false
        }
        pod("Alamofire") {
            version = "5.9"
        }
    }
}

Dank der statischen Typisierung von KTS erhalten KMM-Entwickler Autovervollständigung für Source Sets und Abhängigkeiten, Typüberprüfung der Framework-Konfiguration und die Möglichkeit, Plattformnamen zu refaktorieren. KTS vereinfacht auch das Debugging: Fehler in der KMM-Konfiguration erscheinen als Kotlin-Kompilierungsfehler mit klaren Nachrichten, im Gegensatz zu Groovy, wo Fehler bis zur Ausführung einer Gradle-Aufgabe verborgen bleiben konnten.