settings.gradle: यह क्या है, मॉड्यूल शामिल करना और pluginManagement

settings.gradle क्या है?

settings.gradle (या Kotlin DSL के लिए settings.gradle.kts) एक फ़ाइल है जिसे Gradle Initialization चरण के दौरान निष्पादित करता है। इसमें प्रोजेक्ट पदानुक्रम परिभाषित किया जाता है, मॉड्यूल शामिल किए जाते हैं, और प्लगइन और निर्भरताओं के लिए रिपॉजिटरी कॉन्फ़िगर की जाती हैं। settings.gradle के बिना, Gradle को नहीं पता होता कि कौन से मॉड्यूल बनाने हैं और कौन से प्लगइन उपलब्ध हैं। एकल-मॉड्यूल प्रोजेक्ट में, settings.gradle अनुपस्थित हो सकता है — Gradle डिफ़ॉल्ट मानों का उपयोग करता है, लेकिन मल्टी-मॉड्यूल प्रोजेक्ट के लिए यह अनिवार्य है।

settings.gradle फ़ाइल प्रोजेक्ट रूट में, मूल build.gradle के साथ स्थित होती है। एक सामान्य रूट प्रोजेक्ट संरचना: settings.gradle.kts, build.gradle.kts, gradle.properties, local.properties, gradle/wrapper/। settings.gradle build.gradle से पहले निष्पादित होता है — Initialization चरण के दौरान, Gradle प्रोजेक्ट ट्री (Gradle API में Project) बनाता है। Initialization पूरा होने के बाद, Configuration शुरू होती है — प्रत्येक मॉड्यूल के build.gradle का निष्पादन।

ऐतिहासिक रूप से, settings.gradle Gradle 0.7 (2010) में दिखाई दिया और शुरू में इसमें केवल include निर्देश थे। Gradle के विकास के साथ, pluginManagement (Gradle 6.8), dependencyResolutionManagement (Gradle 7.0) और versionCatalogs (Gradle 7.4) जोड़े गए। आधुनिक settings.gradle एक शक्तिशाली कॉन्फ़िगरेशन फ़ाइल है जो पूरे प्रोजेक्ट के लिए प्लगइन, रिपॉजिटरी और संस्करण प्रबंधन को केंद्रीकृत करती है। Google AGP 8.0 से शुरू होकर Android Gradle Plugin में इन क्षमताओं को लागू करता है।

settings.gradle बनाम build.gradle

settings.gradle प्रोजेक्ट संरचना और वैश्विक सेटिंग्स (प्लगइन, रिपॉजिटरी) का प्रबंधन करता है। build.gradle बिल्ड (निर्भरताएँ, Android कॉन्फ़िगरेशन, कार्य) का प्रबंधन करता है। settings.gradle पहले निष्पादित होता है और Settings API तक पहुँच रखता है। build.gradle बाद में निष्पादित होता है और Project API तक पहुँच रखता है। कोई भी मॉड्यूल-स्तरीय कॉन्फ़िगरेशन (android ब्लॉक, dependencies) settings.gradle में नहीं हो सकता — वह एक त्रुटि होगी।

include के माध्यम से मॉड्यूल शामिल करना

include निर्देश settings.gradle का मूल है। यह Gradle को बताता है कि कौन से मॉड्यूल को बिल्ड में भाग लेना चाहिए। include का तर्क मॉड्यूल पथ वाली एक स्ट्रिंग है: include(":app") रूट स्तर पर एक मॉड्यूल शामिल करता है, include(":core:network") core/network/ उपनिर्देशिका में एक मॉड्यूल शामिल करता है। शुरुआत में कोलन इंगित करता है कि पथ प्रोजेक्ट रूट के सापेक्ष है। include के बाद, Gradl स्वचालित रूप से निर्दिष्ट निर्देशिका में build.gradle ढूँढता है और मॉड्यूल को प्रोजेक्ट ट्री में जोड़ता है।

प्रत्येक include Gradle API में एक Project बनाता है जिसका नाम include स्ट्रिंग के बराबर होता है। प्रोजेक्ट नाम का उपयोग अन्य मॉड्यूल के build.gradle फ़ाइलों में implementation(project(":module")) में किया जाता है। यदि कोई मॉड्यूल include के माध्यम से शामिल नहीं है, तो किसी अन्य मॉड्यूल से उसका संदर्भ “Project not found” त्रुटि उत्पन्न करेगा। Android Studio IDE भी Project पैनल में मॉड्यूल प्रदर्शित करने के लिए settings.gradle का उपयोग करता है — include के बिना मॉड्यूल फ़ाइल ट्री में दिखाई नहीं देते।

include includeBuild("../library-project") के माध्यम से included builds और composite builds का समर्थन करता है। यह संपूर्ण Gradle प्रोजेक्ट को बाहरी मॉड्यूल के रूप में शामिल करने की अनुमति देता है। Included builds एप्लिकेशन के समानांतर लाइब्रेरी विकसित करने के लिए उपयोगी हैं: लाइब्रेरी में परिवर्तन Maven रिपॉजिटरी में प्रकाशित किए बिना तुरंत एप्लिकेशन में दिखाई देते हैं। प्रोडक्शन बिल्ड में, includeBuild को सामान्य Maven निर्भरता से बदल दिया जाता है।

// settings.gradle.kts — सामान्य संरचना
rootProject.name = "MyApp"

// एप्लिकेशन मॉड्यूल
include(":app")
include(":core:network")
include(":core:database")
include(":core:ui")
include(":feature:home")
include(":feature:profile")
include(":feature:settings")

// बाहरी लाइब्रेरी शामिल करना (composite build)
includeBuild("../my-analytics-lib") {
    dependencySubstitution {
        substitute(module("com.example:analytics"))
            .using(project(":analytics"))
    }
}

प्लगइन प्रबंधन ब्लॉक

रिज़ॉल्यूशन रणनीति

pluginManagement settings.gradle में एक ब्लॉक है जो यह निर्धारित करता है कि Gradle प्लगइन कहाँ से लोड किए जाएँ। यह Gradle 6.8 में लागू होने से पहले केंद्रीकृत प्लगइन प्रबंधन के लिए दिखाई दिया। pluginManagement के अंदर हैं: repositories (प्लगइन खोजने के लिए रिपॉजिटरी की सूची), resolutionStrategy (संस्करण समाधान नियम) और plugins (स्पष्ट प्लगइन संस्करण घोषणाएँ)। यदि pluginManagement परिभाषित नहीं है, तो Gradle build.gradle से रिपॉजिटरी का उपयोग करता है — लेकिन प्लगइन घोषित होने के बाद ही खोजे जाते हैं, जिससे त्रुटियाँ होती हैं यदि प्लगइन नहीं मिलता।

Android प्रोजेक्ट्स में, यदि Version Catalogs या Convention Plugins का उपयोग किया जाता है तो pluginManagement अनिवार्य है। pluginManagement के बिना, Gradle build.gradle.kts में लागू करने पर com.android.application प्लगइन नहीं ढूँढ पाएगा। एक सामान्य कॉन्फ़िगरेशन: repositories में google() (Android प्लगइन), mavenCentral() (तृतीय-पक्ष प्लगइन) और gradlePluginPortal() (आधिकारिक Gradle प्लगइन) होते हैं।

pluginManagement plugins का भी समर्थन करता है — संस्करणों के साथ प्लगइन घोषित करना जो बाद में build.gradle में बिना संस्करण निर्दिष्ट किए लागू होते हैं। यह प्लगइन संस्करणों को केंद्रीकृत करता है: यदि 10 मॉड्यूल kotlin-android लागू करते हैं, तो संस्करण pluginManagement में एक बार निर्दिष्ट किया जाता है। महत्वपूर्ण: pluginManagement.plugins केवल एक घोषणा है। प्लगइन स्वयं build.gradle में plugins { id("org.jetbrains.kotlin.android") } के माध्यम से लागू होता है।

pluginManagement {
    repositories {
        google()
        mavenCentral()
        gradlePluginPortal()
        maven { url = "https://jitpack.io" }
    }

    // प्लगइन संस्करण — केंद्रीकृत
    plugins {
        id("com.android.application") version "8.7.0"
        id("com.android.library") version "8.7.0"
        id("org.jetbrains.kotlin.android") version "2.0.21"
        id("com.google.devtools.ksp") version "2.0.21-1.0.25"
    }

    resolutionStrategy {
        // सभी मॉड्यूल के लिए अनिवार्य प्लगइन संस्करण
        eachPlugin {
            if (requested.id.id == "com.google.gms.google-services") {
                useVersion("4.4.2")
            }
        }
    }
}

plugins {
    // प्लगइन लागू करना — apply false (रूट पर लागू न करें)
    id("com.android.application") apply false
    id("org.jetbrains.kotlin.android") apply false
}

निर्भरता रिज़ॉल्यूशन प्रबंधन

repositoriesMode मोड

dependencyResolutionManagement settings.gradle में एक ब्लॉक है जो सभी मॉड्यूल के लिए केंद्रीय रूप से रिपॉजिटरी प्रबंधित करता है। यह Gradle 7.0 में प्रत्येक build.gradle में repositories घोषित करने के विकल्प के रूप में दिखाई दिया। ब्लॉक के अंदर repositoriesMode (मोड: PREFER_PROJECT, PREFER_SETTINGS या FAIL_ON_PROJECT_REPOS) और repositories (रिपॉजिटरी की सूची) सेट किए जाते हैं। यदि repositoriesMode = PREFER_SETTINGS है, तो मॉड्यूल-स्तरीय repositories को अनदेखा किया जाता है — केवल केंद्रीकृत सूची का उपयोग किया जाता है।

repositoriesMode तीन मान ले सकता है। PREFER_SETTINGS — build.gradle से रिपॉजिटरी को अनदेखा किया जाता है, केवल settings.gradle से उपयोग किया जाता है। PREFER_PROJECT — build.gradle रिपॉजिटरी की settings.gradle पर प्राथमिकता होती है। FAIL_ON_PROJECT_REPOS — यदि कोई मॉड्यूल अपनी स्वयं की रिपॉजिटरी घोषित करता है, तो Gradle एक त्रुटि देता है। नए प्रोजेक्ट के लिए, PREFER_SETTINGS अनुशंसित है — यह गारंटी देता है कि सभी मॉड्यूल समान रिपॉजिटरी का उपयोग करते हैं और दोहराव को समाप्त करता है।

repositoriesMode = FAIL_ON_PROJECT_REPOS विशेष रूप से टीमों में उपयोगी है: यदि कोई डेवलपर केवल एक मॉड्यूल में रिपॉजिटरी जोड़ता है और अन्य इसे नहीं देखते हैं, तो “works on my machine” समस्या उत्पन्न होती है। FAIL_ON_PROJECT_REPOS सभी रिपॉजिटरी को settings.gradle में केंद्रीय रूप से घोषित करने के लिए मजबूर करता है, ऐसी स्थितियों को रोकता है। Google AGP 8.0 से शुरू होकर सभी Android प्रोजेक्ट के लिए FAIL_ON_PROJECT_REPOS की अनुशंसा करता है।

dependencyResolutionManagement {
    // FAIL_ON_PROJECT_REPOS — सभी रिपॉजिटरी केवल यहाँ
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)

    repositories {
        google()
        mavenCentral()
        maven { url = "https://jitpack.io" }

        // निजी Maven रिपॉजिटरी
        maven {
            url = "https://maven.pkg.github.com/company/internal-lib"
            credentials {
                username = providers.gradleProperty("gpr.user")
                    .getOrNull() ?: System.getenv("GPR_USER") ?: ""
                password = providers.gradleProperty("gpr.key")
                    .getOrNull() ?: System.getenv("GPR_KEY") ?: ""
            }
        }
    }
}

// build.gradle मॉड्यूल में repositories की अब आवश्यकता नहीं!
// सभी रिपॉजिटरी settings.gradle में केंद्रीकृत

settings.gradle में संस्करण सूची

Version Catalogs TOML फ़ाइल के माध्यम से निर्भरता संस्करणों के प्रबंधन का एक केंद्रीकृत तरीका है। Gradle 7.4 से शुरू होकर, संस्करण सूची सभी Android प्रोजेक्ट के लिए अनुशंसित तंत्र है। gradle/libs.versions.toml फ़ाइल में तीन खंड हैं: [versions] (संस्करण), [libraries] (निर्भरताएँ), [plugins] (प्लगइन)। settings.gradle में, संस्करण सूची @Suppress("UnstableApiUsage") और enableFeaturePreview("VERSION_CATALOGS") (पुराने Gradle संस्करणों में) के माध्यम से जुड़ती है।

संस्करण सूची जोड़ने के बाद, build.gradle में मॉड्यूल निर्भरताएँ libs के माध्यम से निर्दिष्ट की जाती हैं: implementation(libs.retrofit)। IDE libs के लिए ऑटो-पूर्णता प्रदान करता है। सूची स्वचालित रूप से type-safe accessors उत्पन्न करती है: libs.retrofit, libs.kotlin.coroutines, libs.bundles.compose। Bundles निर्भरताओं के समूह हैं जिन्हें एक पंक्ति में शामिल किया जा सकता है। संस्करण सूची विरासत का भी समर्थन करती है — कई TOML फ़ाइलें जोड़ी जा सकती हैं।

संस्करण सूची के लाभ: संस्करणों के लिए एक ही स्थान (सभी build.gradle फ़ाइलों में खोजने की आवश्यकता नहीं); type-safe पहुँच (libs नाम में टाइपो संकलन समय पर पकड़ा जाता है, रनटाइम पर नहीं); स्वचालित अपडेट (Dependabot और Renovate TOML का समर्थन करते हैं); Convention Plugins के साथ संगतता। Google Firebase और AndroidX अपनी स्वयं की TOML सूची वितरित करते हैं। Version Catalogs में माइग्रेट करने के लिए, ऐसे प्लगइन मौजूद हैं जो स्वचालित रूप से build.gradle से TOML में संस्करण स्थानांतरित करते हैं।

# gradle/libs.versions.toml
[versions]
agp = "8.7.0"
kotlin = "2.0.21"
composeBom = "2024.12.01"
retrofit = "2.11.0"
coroutines = "1.9.0"

[libraries]
retrofit = { module = "com.squareup.retrofit2:retrofit", version.ref = "retrofit" }
retrofit-gson = { module = "com.squareup.retrofit2:converter-gson", version.ref = "retrofit" }
kotlin-coroutines = { module = "org.jetbrains.kotlinx:kotlinx-coroutines-core", version.ref = "coroutines" }
compose-bom = { module = "androidx.compose:compose-bom", version.ref = "composeBom" }
compose-ui = { module = "androidx.compose.ui:ui" }

[bundles]
compose = ["compose-ui", "compose-material3"]

[plugins]
android-application = { id = "com.android.application", version.ref = "agp" }
kotlin-android = { id = "org.jetbrains.kotlin.android", version.ref = "kotlin" }

उन्नत सेटिंग्स: includeBuild और प्रायोगिक सुविधाएँ

includeBuild एक समग्र बिल्ड बनाने का निर्देश है: वर्तमान बिल्ड के भाग के रूप में एक बाहरी Gradle प्रोजेक्ट शामिल करना। include (जो एक मॉड्यूल शामिल करता है) के विपरीत, includeBuild अपने स्वयं के settings.gradle, मॉड्यूल और प्लगइन के साथ एक संपूर्ण प्रोजेक्ट शामिल करता है। समग्र बिल्ड का उपयोग इसके लिए किया जाता है: एप्लिकेशन के समानांतर लाइब्रेरी (एनालिटिक्स, नेटवर्किंग) विकसित करना; एक अलग रिपॉजिटरी से Convention Plugins शामिल करना; build-logic मॉड्यूल को एकीकृत करना।

प्रायोगिक सुविधाएँ (Incubating Features) Gradle के प्रायोगिक विकल्प हैं जो enableFeaturePreview("FEATURE_NAME") के माध्यम से सक्षम होते हैं। AGP 8.7+ में, उपलब्ध सुविधाओं में शामिल हैं: TYPESAFE_PROJECT_ACCESSORS (मल्टी-मॉड्यूल प्रोजेक्ट में प्रोजेक्ट तक type-safe पहुँच: project(":core:network") के बजाय, आप projects.core.network लिख सकते हैं), STABLE_CONFIGURATION_CACHE (स्थिर कॉन्फ़िगरेशन कैशिंग), ARTIFACT_TRANSFORM_FOR_INTERNAL_TEST (आर्टिफैक्ट परिवर्तन)। प्रायोगिक सुविधाओं को प्रोडक्शन में सक्षम किया जा सकता है, लेकिन API भविष्य के संस्करणों में बदल सकता है।

Gradle Enterprise और Build Scan भी settings.gradle के माध्यम से कॉन्फ़िगर किए जाते हैं: plugins { id("com.gradle.enterprise") } एक gradleEnterprise ब्लॉक के साथ। Build Scan एक क्लाउड सेवा है जो प्रत्येक बिल्ड के बारे में विस्तृत जानकारी दिखाती है: प्रत्येक कार्य का निष्पादन समय, कैशिंग, त्रुटियाँ। Build Scan सक्षम करने से बिल्ड गति समस्याओं का निदान करने में मदद मिलती है। Build Scan ओपन-सोर्स प्रोजेक्ट के लिए मुफ़्त है।

// प्रायोगिक सुविधाएँ
enableFeaturePreview("TYPESAFE_PROJECT_ACCESSORS")
enableFeaturePreview("STABLE_CONFIGURATION_CACHE")

// Gradle Enterprise / Build Scan
plugins {
    id("com.gradle.enterprise") version "3.18"
}

gradleEnterprise {
    buildScan {
        termsOfServiceUrl = "https://gradle.com/terms-of-service"
        termsOfServiceAgree = "yes"
        publishAlwaysIf(true)
    }
}

// build.gradle में type-safe project accessors का उपयोग
// इसके बजाय: implementation(project(":core:network"))
// आप कर सकते हैं: implementation(projects.core.network)