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 افعال کا اعلان کرنے کی اجازت دیتا ہے۔ یہ خاص طور پر بار بار آنے والی کنفیگریشنز جیسے دستخطی کنفیگریشنز یا ورژن مینجمنٹ کے لیے آسان ہے۔ جامد ٹائپنگ کی بدولت، ان افعال کو کمپائل وقت پر پیرامیٹر کی تصدیق کے ساتھ بلایا جا سکتا ہے، 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 اور روٹ 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 کے کام انجام دینے تک پوشیدہ رہ سکتی تھیں۔