Gradle KTS — यह क्या है, Gradle के लिए Kotlin DSL और सिंटैक्स

Gradle KTS क्या है?

Gradle KTS एक Kotlin DSL (डोमेन स्पेसिफिक लैंग्वेज) है जो Gradle कॉन्फ़िगरेशन फ़ाइलें लिखने के लिए Groovy का विकल्प प्रदान करता है। Groovy सिंटैक्स के बजाय, डेवलपर Kotlin का उपयोग करते हैं — एक सख्ती से टाइप की गई भाषा जो कंपाइल समय पर कॉन्फ़िगरेशन की शुद्धता को सत्यापित करती है। KTS को पहली बार 2018 में Gradle 5.0 में एक प्रायोगिक सुविधा के रूप में पेश किया गया था और Gradle 6.0 में स्थिरता तक पहुँचा।

KTS का मुख्य उद्देश्य बिल्ड स्क्रिप्ट में Groovy की कमियों को दूर करना है। Groovy एक डायनामिक रूप से टाइप की गई भाषा है जिसमें कॉन्फ़िगरेशन त्रुटियाँ केवल रनटाइम पर कार्य निष्पादित करते समय दिखाई देती हैं। KTS Kotlin की स्टैटिक टाइपिंग के कारण कोड संपादन चरण में ही समान त्रुटियों का पता लगाने की अनुमति देता है। इसके अतिरिक्त, KTS पूर्ण प्रकार दस्तावेज़ीकरण के साथ Gradle API तक पहुँच प्रदान करता है, जो जटिल कॉन्फ़िगरेशन ब्लॉकों को सीखने और उपयोग करने को काफी सरल बनाता है।

KTS इकोसिस्टम सभी प्रमुख टूल्स द्वारा समर्थित है: Android Studio, IntelliJ IDEA, Kotlin प्लगइन के साथ VS Code और Gradle Build Tool। सभी आधुनिक प्लगइन (Android Gradle Plugin, Kotlin Multiplatform, Protobuf, Compose) स्पष्ट प्रकारों के साथ Kotlin-अनुकूल API प्रदान करते हैं, जो KTS को नए प्रोजेक्ट्स के लिए पसंदीदा विकल्प बनाता है।

Gradle KTS कैसे काम करता है

Gradle KTS .gradle.kts फ़ाइलों को प्रोसेस करने के लिए Kotlin कंपाइलर का उपयोग करता है। Gradle एक्सटेंशन को पहचानता है और स्क्रिप्ट को Kotlin स्क्रिप्टिंग इंजन को भेजता है, जो उन्हें क्लासेस में कंपाइल करता है। फिर ये क्लासेस प्रोजेक्ट मॉडल बनाने के लिए Gradle द्वारा निष्पादित की जाती हैं। Groovy से मुख्य अंतर: KTS स्क्रिप्ट पहले से कंपाइल की जाती हैं, डायनामिक रूप से इंटरप्रिट नहीं की जाती हैं, जिससे कार्य निष्पादन शुरू होने से पहले त्रुटियों का पता लगाया जा सकता है।

KTS आर्किटेक्चर kotlin-scripting पर आधारित है। प्रत्येक .gradle.kts फ़ाइल Gradle API के अंतर्निहित आयात के साथ एक Kotlin स्क्रिप्ट है। डेवलपर किसी भी Kotlin निर्माण का उपयोग कर सकता है: एक्सटेंशन फ़ंक्शन, लैम्ब्डा, डेटा क्लासेस, और बिल्ड स्क्रिप्ट के अंदर सहायक फ़ंक्शन भी घोषित कर सकता है। 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 बनाम Groovy: तुलना

Groovy Gradle के लिए मूल DSL था और पूरी तरह से समर्थित बना हुआ है। हालाँकि, KTS कई लाभ प्रदान करता है जो इसे नए प्रोजेक्ट्स के लिए अनुशंसित विकल्प बनाते हैं। स्टैटिक टाइपिंग, IDE में बेहतर संपादन प्रदर्शन और सख्त सिंटैक्स KTS पर स्विच करने के मुख्य कारण हैं। वहीं, Groovy सरल कॉन्फ़िगरेशन के लिए संक्षिप्तता में अपना लाभ बनाए रखता है।

स्क्रिप्ट कंपाइलेशन के बाद KTS और Groovy पर बिल्ड प्रदर्शन लगभग समान है। पहली बार चलाने या कैश साफ़ करने के बाद KTS स्क्रिप्ट को कंपाइल होने में अधिक समय लगता है, लेकिन बाद के बिल्ड Groovy स्क्रिप्ट के समान गति से चलते हैं। Gradle कंपाइल की गई KTS स्क्रिप्ट को बिल्ड डायरेक्टरी में कैश करता है, इसलिए स्क्रिप्ट बदलने पर ही पुनः कंपाइलेशन होता है।

2026 में KTS और Groovy के बीच चुनाव स्पष्ट है: नए प्रोजेक्ट्स के लिए — KTS। Google, JetBrains और Gradle सभी नए प्रोजेक्ट्स के लिए KTS की अनुशंसा करते हैं। Groovy लिगेसी प्रोजेक्ट्स के रखरखाव के लिए प्रासंगिक बना हुआ है जहाँ कॉन्फ़िगरेशन की मात्रा या KTS के साथ असंगत विशिष्ट प्लगइन के कारण माइग्रेशन अव्यावहारिक है।

कोड उदाहरण: KTS पर बिल्ड स्क्रिप्ट

Android, Kotlin Multiplatform और Compose Multiplatform के लिए KTS में विशिष्ट कॉन्फ़िगरेशन ब्लॉक देखें। KTS के साथ Android प्रोजेक्ट को buildTypes और productFlavors कॉन्फ़िगरेशन में स्पष्ट प्रकार निर्दिष्ट करने की आवश्यकता होती है। नीचे दिया गया उदाहरण दो फ्लेवर वाले एप्लिकेशन को सेट अप करना दर्शाता है।

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 मॉड्यूल कॉन्फ़िगरेशन में लक्ष्य प्लेटफ़ॉर्म और सोर्स सेट सेट करना शामिल है। नीचे दिया गया उदाहरण 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 फ़ंक्शन घोषित करने की अनुमति देता है। यह विशेष रूप से दोहराए जाने वाले कॉन्फ़िगरेशन जैसे signing configs या संस्करण प्रबंधन के लिए सुविधाजनक है। स्टैटिक टाइपिंग के कारण, ऐसे फ़ंक्शन को कंपाइल समय पर पैरामीटर सत्यापन के साथ कॉल किया जा सकता है, जो Google Play पर प्रकाशित करने से पहले signing कॉन्फ़िगरेशन में त्रुटियों को समाप्त करता है।

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 और रूट build.gradle को पहले माइग्रेट किया जा सकता है क्योंकि वे मॉड्यूल प्लगइन पर निर्भर नहीं होते हैं। Google settings.gradle.kts, फिर रूट build.gradle.kts, और उसके बाद ही मॉड्यूल से माइग्रेशन शुरू करने की अनुशंसा करता है।

माइग्रेशन के मुख्य चरणों में शामिल हैं: क्लोज़र सिंटैक्स को लैम्ब्डा से बदलना, असाइनमेंट के लिए = चिह्न जोड़ना, स्ट्रिंग कीज़ को टाइप किए गए स्थिरांक से बदलना और स्पष्ट वेरिएबल टाइपिंग। Android Studio सरल ब्लॉकों के लिए स्वचालित Groovy → KTS रूपांतरण प्रदान करता है, लेकिन नेस्टेड क्लोज़र वाले जटिल कॉन्फ़िगरेशन के लिए मैन्युअल पुनर्लेखन की आवश्यकता होती है।

विशिष्ट माइग्रेशन समस्याओं में अंतर्निहित Groovy विधि कॉल शामिल हैं जिनका कोई Kotlin समतुल्य नहीं है, और ऐसे प्लगइन जो Kotlin-अनुकूल API प्रदान नहीं करते हैं। पहली समस्या के लिए, Gradle withGroovyBuilder के माध्यम से संगतता प्रदान करता है — एक तंत्र जो KTS से Groovy विधियों को कॉल करने की अनुमति देता है। दूसरी के लिए — प्लगइन अपडेट की प्रतीक्षा करना या पूर्ण माइग्रेशन तक इसे Groovy मॉड्यूल में उपयोग करना आवश्यक है।

Kotlin Multiplatform के लिए Gradle KTS

Kotlin Multiplatform प्राथमिक प्रोजेक्ट है जहाँ KTS एक अनिवार्य आवश्यकता है। kotlin multiplatform प्लगइन लक्ष्य प्लेटफ़ॉर्म, सोर्स सेट और फ्रेमवर्क बाइनरी के कॉन्फ़िगरेशन के लिए एक्सटेंशन प्रदान करता है जो केवल Kotlin DSL के माध्यम से उपलब्ध हैं। Groovy मल्टीप्लेटफ़ॉर्म कॉन्फ़िगरेशन का सही ढंग से समर्थन नहीं करता है, इसलिए KMM प्रोजेक्ट विशेष रूप से KTS का उपयोग करते हैं।

KTS में KMM कॉन्फ़िगरेशन में गैर-मानक ब्लॉक शामिल हैं: प्लेटफ़ॉर्म निर्दिष्ट करने के लिए kotlin.target, सामान्य और प्लेटफ़ॉर्म-विशिष्ट कोड को व्यवस्थित करने के लिए kotlin.sourceSets, CocoaPods एकीकरण के लिए kotlin.cocoapods और JDK चयन के लिए kotlin.jvmToolchain। प्रत्येक ब्लॉक में Android Studio में ऑटो-कम्प्लीशन के साथ सख्ती से टाइप किया गया API है, जो कई प्लेटफ़ॉर्म वाले जटिल 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 डेवलपर्स को सोर्स सेट और निर्भरताओं के लिए ऑटो-कम्प्लीशन, फ्रेमवर्क कॉन्फ़िगरेशन की प्रकार जाँच और प्लेटफ़ॉर्म नामों को रीफ़ैक्टर करने की क्षमता मिलती है। KTS डिबगिंग को भी सरल बनाता है: KMM कॉन्फ़िगरेशन में त्रुटियाँ स्पष्ट संदेशों के साथ Kotlin कंपाइलेशन त्रुटियों के रूप में दिखाई देती हैं, Groovy के विपरीत जहाँ त्रुटियाँ Gradle कार्य निष्पादित होने तक छिपी रह सकती थीं।