Gradle KTS — τι είναι, Kotlin DSL για Gradle και σύνταξη

Τι είναι το Gradle KTS;

Gradle KTS — είναι Kotlin DSL (Domain Specific Language), που παρέχει μια εναλλακτική λύση στο Groovy για τη σύνταξη αρχείων διαμόρφωσης Gradle. Αντί για σύνταξη Groovy, οι προγραμματιστές χρησιμοποιούν Kotlin — μια αυστηρά τυποποιημένη γλώσσα που ελέγχει την ορθότητα της διαμόρφωσης στο στάδιο μεταγλώττισης. Το KTS παρουσιάστηκε για πρώτη φορά στο Gradle 5.0 το 2018 ως πειραματική λειτουργία και έφτασε σε σταθερότητα στο Gradle 6.0.

Ο κύριος στόχος του KTS είναι να εξαλείψει τις ελλείψεις του Groovy στα build σενάρια. Groovy — μια δυναμικά τυποποιημένη γλώσσα, στην οποία τα σφάλματα διαμόρφωσης εμφανίζονται μόνο κατά το runtime κατά την εκτέλεση εργασιών. Το KTS επιτρέπει την ανίχνευση των ίδιων σφαλμάτων στο στάδιο επεξεργασίας κώδικα χάρη στη στατική τυποποίηση της Kotlin. Επιπλέον, το KTS παρέχει πρόσβαση στο API του Gradle με πλήρη τεκμηρίωση τύπων, γεγονός που διευκολύνει σημαντικά την εκμάθηση και χρήση σύνθετων μπλοκ διαμόρφωσης.

Το οικοσύστημα KTS υποστηρίζεται από όλα τα κύρια εργαλεία: Android Studio, IntelliJ IDEA, VS Code με το πρόσθετο Kotlin και το Gradle Build Tool. Όλα τα σύγχρονα πρόσθετα (Android Gradle Plugin, Kotlin Multiplatform, Protobuf, Compose) παρέχουν ένα φιλικό προς το Kotlin API με ρητούς τύπους, καθιστώντας το KTS την προτιμώμενη επιλογή για νέα έργα.

Πώς λειτουργεί το Gradle KTS

Gradle KTS χρησιμοποιεί τον μεταγλωττιστή Kotlin για την επεξεργασία αρχείων .gradle.kts. Το Gradle αναγνωρίζει την επέκταση και στέλνει τα σενάρια στον μηχανή σεναρίων Kotlin, ο οποίος τα μεταγλωττίζει σε κλάσεις. Αυτές οι κλάσεις στη συνέχεια εκτελούνται από το Gradle για τη δόμηση του μοντέλου έργου. Η βασική διαφορά από το Groovy: τα σενάρια KTS μεταγλωττίζονται εκ των προτέρων, δεν ερμηνεύονται δυναμικά, επιτρέποντας τον εντοπισμό σφαλμάτων πριν από την έναρξη εκτέλεσης εργασιών.

Η αρχιτεκτονική του KTS βασίζεται στο kotlin-scripting. Κάθε αρχείο .gradle.kts είναι ένα σενάριο Kotlin με σιωπηρές εισαγωγές του API Gradle. Ο προγραμματιστής μπορεί να χρησιμοποιήσει οποιεσδήποτε κατασκευές Kotlin: συναρτήσεις επέκτασης, λάμδα, κλάσεις δεδομένων, ακόμη και να δηλώσει βοηθητικές συναρτήσεις μέσα στο build σενάριο. Το Gradle παρέχει ένα σύνολο συναρτήσεων επέκτασης για τυποποιημένη διαμόρφωση μπλοκ: dependencies, android, kotlin και άλλων.

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

Μετατροπή τύπων στο KTS

Μία από τις βασικές διαφορές μεταξύ KTS και Groovy είναι η εργασία με τύπους. Στο Groovy, όλες οι διαμορφώσεις δέχονται Object, στο KTS — συγκεκριμένους τύπους Kotlin. Για παράδειγμα, το compileSdk δέχεται Int, όχι συμβολοσειρά. Αυτό εξαλείφει σφάλματα που σχετίζονται με λανθασμένο τύπο: στο Groovy τα compileSdk 34 και compileSdk “34” λειτουργούν ίδια, στο KTS μόνο η πρώτη παραλλαγή. Αυτή η αυστηρότητα καθιστά τη διαμόρφωση πιο προβλέψιμη και τεκμηριωμένη.

Gradle KTS vs Groovy: σύγκριση

Groovy ήταν το αρχικό DSL για το Gradle και παραμένει πλήρως υποστηριζόμενο. Ωστόσο, το KTS προσφέρει μια σειρά από πλεονεκτήματα που το καθιστούν συνιστώμενο για νέα έργα. Στατική τυποποίηση, καλύτερη απόδοση επεξεργασίας στο IDE και αυστηρότερη σύνταξη — οι κύριοι λόγοι μετάβασης στο KTS. Ταυτόχρονα, το Groovy διατηρεί το πλεονέκτημα της συνοπτικότητας για απλές διαμορφώσεις.

Η απόδοση δόμησης στο KTS και το Groovy είναι πρακτικά ταυτόσημη μετά τη μεταγλώττιση των σεναρίων. Τα σενάρια KTS μεταγλωττίζονται περισσότερο κατά την πρώτη εκκίνηση ή μετά τον καθαρισμό της προσωρινής μνήμης, αλλά οι επόμενες δομήσεις λειτουργούν με την ίδια ταχύτητα με τα σενάρια Groovy. Το Gradle αποθηκεύει στην προσωρινή μνήμη τα μεταγλωττισμένα σενάρια KTS στον κατάλογο build, επομένως η επαναμεταγλώττιση γίνεται μόνο όταν αλλάξει το σενάριο.

Η επιλογή μεταξύ KTS και Groovy το 2026 είναι προφανής: για νέα έργα — KTS. Η Google, η JetBrains και το Gradle συνιστούν KTS για όλα τα νέα έργα. Το Groovy παραμένει σχετικό για την υποστήριξη παλαιότερων έργων, όπου η μετεγκατάσταση δεν είναι σκόπιμη λόγω του όγκου των διαμορφώσεων ή των συγκεκριμένων πρόσθετων που δεν είναι συμβατά με το KTS.

Παραδείγματα κώδικα: build σενάρια σε KTS

Ας εξετάσουμε τυπικά μπλοκ διαμόρφωσης σε KTS για Android, Kotlin Multiplatform και Compose Multiplatform. Έργο Android με KTS απαιτεί ρητό καθορισμό τύπων στη διαμόρφωση των buildTypes και productFlavors. Το παρακάτω παράδειγμα δείχνει τη διαμόρφωση μιας εφαρμογής με δύο 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"
        }
    }
}

Για Kotlin Multiplatform το KTS είναι υποχρεωτικό — το Groovy δεν υποστηρίζει σωστά τη διαμόρφωση πολυπλατφορμικών μονάδων. Η διαμόρφωση μιας μονάδας KMM περιλαμβάνει ρύθμιση πλατφορμών-στόχων και source set. Το παρακάτω παράδειγμα δείχνει τη διαμόρφωση μιας κοινόχρηστης μονάδας με iOS και 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")
        }
    }
}

Βοηθητικές συναρτήσεις και προσαρμοσμένες εργασίες

Το KTS επιτρέπει τη δήλωση βοηθητικών συναρτήσεων Kotlin μέσα στο build σενάριο. Αυτό είναι ιδιαίτερα βολικό για επαναλαμβανόμενες διαμορφώσεις, όπως οι ρυθμίσεις υπογραφής ή η διαχείριση εκδόσεων. Χάρη στη στατική τυποποίηση, τέτοιες συναρτήσεις μπορούν να κληθούν με έλεγχο παραμέτρων στο στάδιο μεταγλώττισης, εξαλείφοντας σφάλματα στις ρυθμίσεις υπογραφής πριν από τη δημοσίευση στο 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")
            }
        }
    }
}

// Χρήση σε build.gradle.kts
configureSigning()

Μετεγκατάσταση από Groovy σε KTS

Μετεγκατάσταση από Groovy σε KTS — μια διαδικασία που μπορεί να εκτελεστεί σταδιακά. Το Gradle υποστηρίζει μικτά έργα, όπου ένα μέρος των μονάδων χρησιμοποιεί Groovy (build.gradle) και ένα μέρος KTS (build.gradle.kts). Τα settings.gradle και root build.gradle μπορούν να μετατραπούν πρώτα, καθώς δεν εξαρτώνται από τα πρόσθετα μονάδων. Η Google συνιστά να ξεκινήσετε τη μετεγκατάσταση με settings.gradle.kts, στη συνέχεια root build.gradle.kts, και μόνο μετά τις μονάδες.

Τα κύρια βήματα μετεγκατάστασης περιλαμβάνουν: αντικατάσταση σύνταξης closures με λάμδα, προσθήκη = για ανάθεση, αντικατάσταση κλειδιών συμβολοσειράς με τυποποιημένες σταθερές και ρητή τυποποίηση μεταβλητών. Το Android Studio παρέχει αυτόματη μετατροπή Groovy → KTS για απλά μπλοκ, αλλά σύνθετες διαμορφώσεις με ένθετα closures απαιτούν χειροκίνητη επανεγγραφή.

Τυπικά προβλήματα κατά τη μετεγκατάσταση περιλαμβάνουν σιωπηρές κλήσεις μεθόδων Groovy που δεν έχουν αντίστοιχο Kotlin και πρόσθετα που δεν παρέχουν φιλικό προς το Kotlin API. Για την επίλυση του πρώτου προβλήματος, το Gradle παρέχει συμβατότητα μέσω withGroovyBuilder — έναν μηχανισμό που επιτρέπει την κλήση μεθόδων Groovy από KTS. Για το δεύτερο — πρέπει να περιμένετε την ενημέρωση του πρόσθετου ή να το χρησιμοποιήσετε στη μονάδα Groovy μέχρι την πλήρη μετεγκατάσταση.

Gradle KTS για Kotlin Multiplatform

Kotlin Multiplatform — το κύριο έργο στο οποίο το KTS είναι υποχρεωτική απαίτηση. Το πρόσθετο kotlin multiplatform παρέχει επεκτάσεις για τη διαμόρφωση πλατφορμών-στόχων, source set και δυαδικών αρχείων framework, οι οποίες είναι διαθέσιμες μόνο μέσω Kotlin DSL. Το Groovy δεν υποστηρίζει σωστά τη διαμόρφωση πολλαπλών πλατφορμών, επομένως τα έργα KMM χρησιμοποιούν αποκλειστικά KTS.

Η διαμόρφωση KMM σε KTS περιλαμβάνει μη τυπικά μπλοκ: kotlin.target για τον καθορισμό πλατφορμών, kotlin.sourceSets για την οργάνωση κοινού και πλατφορμικού κώδικα, kotlin.cocoapods για ενοποίηση με CocoaPods και kotlin.jvmToolchain για επιλογή JDK. Κάθε μπλοκ έχει ένα αυστηρά τυποποιημένο API με αυτόματη συμπλήρωση στο Android Studio, το οποίο είναι ιδιαίτερα πολύτιμο για τη σύνθετη διαμόρφωση έργων KMM με πολλαπλές πλατφόρμες.

kotlin {
    iosArm64()
    iosSimulatorArm64()
    iosX64()

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

Χάρη στη στατική τυποποίηση του KTS, οι προγραμματιστές KMM λαμβάνουν αυτόματη συμπλήρωση για source set και εξαρτήσεις, έλεγχο τύπων διαμόρφωσης framework και δυνατότητα αναδόμησης ονομάτων πλατφορμών. Το KTS επίσης απλοποιεί τον εντοπισμό σφαλμάτων: τα σφάλματα στη διαμόρφωση KMM εμφανίζονται ως σφάλματα μεταγλώττισης Kotlin με κατανοητά μηνύματα, σε αντίθεση με το Groovy όπου τα σφάλματα μπορούσαν να κρυφτούν μέχρι την εκτέλεση της εργασίας Gradle.