Gradle KTS — ano ito, Kotlin DSL para sa Gradle at syntax

Ano ang Gradle KTS?

Gradle KTS — ay Kotlin DSL (Domain Specific Language), na nagbibigay ng alternatibo sa Groovy para sa pagsulat ng mga configuration file ng Gradle. Sa halip na Groovy syntax, ang mga developer ay gumagamit ng Kotlin — isang mahigpit na naka-type na wika na sumusuri sa tama ng configuration sa yugto ng compilation. Ang KTS ay unang ipinakilala sa Gradle 5.0 noong 2018 bilang isang eksperimental na feature at umabot sa stability sa Gradle 6.0.

Ang pangunahing layunin ng KTS ay alisin ang mga kakulangan ng Groovy sa mga build script. Groovy — isang dinamikong naka-type na wika, kung saan ang mga error sa configuration ay lumalabas lamang sa runtime sa pag-execute ng mga task. Ang KTS ay nagbibigay-daan sa pag-detect ng parehong mga error sa yugto ng pag-edit ng code dahil sa static typing ng Kotlin. Dagdag pa, ang KTS ay nagbibigay ng access sa Gradle API na may kumpletong dokumentasyon ng mga type, na lubhang nagpapadali sa pag-aaral at paggamit ng mga kumplikadong configuration block.

Ang ecosystem ng KTS ay sinusuportahan ng lahat ng pangunahing tool: Android Studio, IntelliJ IDEA, VS Code na may Kotlin plugin at Gradle Build Tool. Lahat ng modernong plugin (Android Gradle Plugin, Kotlin Multiplatform, Protobuf, Compose) ay nagbibigay ng Kotlin-friendly na API na may mga explicit na type, na ginagawang mas piniling opsyon ang KTS para sa mga bagong proyekto.

Paano gumagana ang Gradle KTS

Gradle KTS ay gumagamit ng Kotlin compiler para sa pagproseso ng mga .gradle.kts file. Kinikilala ng Gradle ang extension at ipinapasa ang mga script sa Kotlin script engine, na nag-compile ng mga ito sa mga class. Ang mga class na ito ay isinasagawa ng Gradle para sa pagbuo ng modelo ng proyekto. Ang pangunahing pagkakaiba sa Groovy: ang mga KTS script ay ini-compile nang maaga, hindi dinamikong ini-interpret, na nagbibigay-daan sa pag-detect ng mga error bago magsimula ang pag-execute ng task.

Ang arkitektura ng KTS ay batay sa kotlin-scripting. Ang bawat .gradle.kts file ay isang Kotlin script na may implicit na import ng Gradle API. Ang developer ay maaaring gumamit ng anumang Kotlin constructs: extension functions, lambda, data classes, at kahit magdeklara ng mga helper function sa loob ng build script. Ang Gradle ay nagbibigay ng set ng extension functions para sa naka-type na configuration ng mga block: dependencies, android, kotlin, at iba pa.

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")
}

Conversion ng type sa KTS

Isa sa mga pangunahing pagkakaiba sa pagitan ng KTS at Groovy ay ang pagtatrabaho sa mga type. Sa Groovy, lahat ng configuration ay tumatanggap ng Object, sa KTS — mga konkretong Kotlin type. Halimbawa, ang compileSdk ay tumatanggap ng Int, hindi string. Inaalis nito ang mga error na may kaugnayan sa maling type: sa Groovy, ang compileSdk 34 at compileSdk “34” ay parehong gumagana, sa KTS ay ang unang variant lamang. Ang ganitong pagiging mahigpit ay ginagawang mas predictable at dokumentado ang configuration.

Gradle KTS vs Groovy: paghahambing

Groovy ay ang orihinal na DSL para sa Gradle at nananatiling ganap na suportado. Gayunpaman, ang KTS ay nag-aalok ng ilang mga bentaha na ginagawa itong inirerekomenda para sa mga bagong proyekto. Static typing, mas mahusay na pagganap sa pag-edit sa IDE, at mas mahigpit na syntax — ang mga pangunahing dahilan para lumipat sa KTS. Kasabay nito, pinapanatili ng Groovy ang bentahe ng pagiging maikli para sa mga simpleng configuration.

Ang performance ng build sa KTS at Groovy ay halos magkapareho pagkatapos ng compilation ng mga script. Ang mga KTS script ay mas matagal mag-compile sa unang pagtakbo o pagkatapos ng pag-clear ng cache, ngunit ang mga sumusunod na build ay gumagana sa parehong bilis ng Groovy script. Gradle ay nag-cache ng mga naka-compile na KTS script sa build directory, kaya ang recompilation ay nangyayari lamang kapag nagbago ang script.

Ang pagpili sa pagitan ng KTS at Groovy sa 2026 ay malinaw: para sa mga bagong proyekto — KTS. Google, JetBrains at Gradle ay nagrerekomenda ng KTS para sa lahat ng bagong proyekto. Ang Groovy ay nananatiling may kaugnayan para sa suporta ng mga legacy na proyekto kung saan ang migrasyon ay hindi praktikal dahil sa dami ng configuration o mga spesipikong plugin na hindi tugma sa KTS.

Mga halimbawa ng code: build script sa KTS

Tingnan natin ang mga tipikal na configuration block sa KTS para sa Android, Kotlin Multiplatform at Compose Multiplatform. Android project na may KTS ay nangangailangan ng explicit na pagtukoy ng mga type sa configuration ng buildTypes at productFlavors. Ang halimbawa sa ibaba ay nagpapakita ng configuration ng isang app na may dalawang flavour.

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"
        }
    }
}

Para sa Kotlin Multiplatform, ang KTS ay mandatory — hindi sinusuportahan ng Groovy nang tama ang configuration ng multi-platform modules. Ang configuration ng KMM module ay kinabibilangan ng pag-set ng target platforms at source set. Ang halimbawa sa ibaba ay nagpapakita ng configuration ng shared module na may iOS at 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")
        }
    }
}

Mga helper function at custom na task

Pinapayagan ng KTS ang pagdeklara ng mga helper Kotlin function sa loob ng build script. Ito ay lalong maginhawa para sa mga paulit-ulit na configuration tulad ng signing configs o version management. Dahil sa static typing, ang mga ganitong function ay maaaring tawagin na may pagsusuri ng parameter sa yugto ng compilation, na nag-aalis ng mga error sa signing configuration bago ang pag-publish sa Google Play.

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")
            }
        }
    }
}

// Paggamit sa build.gradle.kts
configureSigning()

Migrasyon mula Groovy patungong KTS

Migrasyon mula Groovy patungong KTS — isang proseso na maaaring gawin nang paunti-unti. Sinusuportahan ng Gradle ang mga mixed project kung saan ang ilang modyul ay gumagamit ng Groovy (build.gradle) at ang iba ay gumagamit ng KTS (build.gradle.kts). Ang settings.gradle at root build.gradle ay maaaring i-convert muna dahil hindi sila nakadepende sa mga plugin ng modyul. Inirerekomenda ng Google na simulan ang migrasyon sa settings.gradle.kts, pagkatapos ay root build.gradle.kts, at pagkatapos lamang ang mga modyul.

Ang mga pangunahing hakbang ng migrasyon ay kinabibilangan ng: pagpapalit ng closure syntax ng lambda, pagdaragdag ng = sign para sa pagtatalaga, pagpapalit ng string key ng mga naka-type na constant, at explicit na pag-type ng mga variable. Android Studio ay nagbibigay ng awtomatikong conversion ng Groovy → KTS para sa mga simpleng block, ngunit ang mga kumplikadong configuration na may nested closures ay nangangailangan ng manual na pagsulat muli.

Ang mga karaniwang problema sa migrasyon ay kinabibilangan ng implicit na tawag sa mga pamamaraan ng Groovy na walang katumbas na Kotlin at mga plugin na hindi nagbibigay ng Kotlin-friendly na API. Para sa unang problema, ang Gradle ay nagbibigay ng compatibility sa pamamagitan ng withGroovyBuilder — isang mekanismo na nagbibigay-daan sa pagtawag ng mga Groovy method mula sa KTS. Para sa pangalawa — maghintay para sa update ng plugin o gamitin ito sa Groovy module hanggang sa kumpletong migrasyon.

Gradle KTS para sa Kotlin Multiplatform

Kotlin Multiplatform — ang pangunahing proyekto kung saan ang KTS ay isang mandatoryong pangangailangan. Ang kotlin multiplatform plugin ay nagbibigay ng mga extension para sa configuration ng target platforms, source set, at framework binaries na available lamang sa pamamagitan ng Kotlin DSL. Hindi sinusuportahan ng Groovy nang tama ang multi-platform configuration, kaya ang mga KMM project ay eksklusibong gumagamit ng KTS.

Ang configuration ng KMM sa KTS ay kinabibilangan ng mga hindi standard na block: kotlin.target para sa pagtukoy ng platforms, kotlin.sourceSets para sa pag-oorganisa ng shared at platform code, kotlin.cocoapods para sa integration sa CocoaPods, at kotlin.jvmToolchain para sa pagpili ng JDK. Ang bawat block ay may mahigpit na naka-type na API na may autocomplete sa Android Studio, na lalong mahalaga para sa kumplikadong configuration ng KMM project na may maraming platform.

kotlin {
    iosArm64()
    iosSimulatorArm64()
    iosX64()

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

Dahil sa static typing ng KTS, ang mga KMM developer ay nakakakuha ng autocomplete para sa source set at dependencies, type checking ng framework configuration, at posibilidad ng refactoring ng mga platform name. KTS ay nagpapadali din ng debugging: ang mga error sa KMM configuration ay ipinapakita bilang Kotlin compilation error na may naiintindihang mensahe, hindi tulad ng Groovy kung saan ang mga error ay maaaring itago hanggang sa pag-execute ng Gradle task.