Gradle डिपेंडेंसी रिज़ॉल्यूशन

आपकी बिल्ड फ़ाइलें, डायरेक्ट डिपेंडेंसी के बारे में बताती हैं. हालांकि, उनमें से हर डिपेंडेंसी के लिए, अन्य डिपेंडेंसी की ज़रूरत पड़ सकती है. इन ट्रांज़िशन डिपेंडेंसी की वजह से, आपके डिपेंडेंसी ग्राफ़ का साइज़ तेज़ी से बढ़ता है. साथ ही, अक्सर इसमें एक-दूसरे से मेल न खाने वाले वर्शन भी शामिल होते हैं.

minor (नई सुविधाएं) या patch (बग ठीक करने वाले) हिस्सों में बदलाव होने पर, लाइब्रेरी के काम करने की संभावना अब भी बनी रहती है. साथ ही, आपके ऐप्लिकेशन पर इसका असर पड़ने की संभावना भी कम होती है.

उदाहरण के लिए, मान लें कि आपका ऐप्लिकेशन लाइब्रेरी A और लाइब्रेरी B पर निर्भर करता है, जो बदले में लाइब्रेरी C के अलग-अलग वर्शन पर निर्भर करती हैं.

इस मामले में, Gradle डिफ़ॉल्ट रूप से लाइब्रेरी C का नया वर्शन चुनता है. इससे, कंपाइलेशन या रनटाइम से जुड़ी समस्याएं हो सकती हैं. इस उदाहरण में, लाइब्रेरी C को 2.1.1 पर अपडेट कर दिया गया है. हालांकि, ध्यान दें कि लाइब्रेरी A ने लाइब्रेरी C के 1.0.3 वर्शन का अनुरोध किया था. वर्शन नंबर का ज़्यादातर हिस्सा बदल गया है. इससे पता चलता है कि वर्शन में ऐसे बदलाव किए गए हैं जो साथ काम नहीं करते. जैसे, हटाए गए फ़ंक्शन या टाइप. इस वजह से, लाइब्रेरी A से किए गए कॉल क्रैश हो सकते हैं.

आपके ऐप्लिकेशन में सीधे तौर पर निर्भरताएं हो सकती हैं, जो ट्रांज़िटिव निर्भरताएं भी हैं.

इस तरह के मामले में, ट्रांज़िशनरी डिपेंडेंसी के नए वर्शन, उस वर्शन को बदल सकते हैं जिसका अनुरोध आपने अपने ऐप्लिकेशन में सीधे तौर पर किया है.

Gradle, ग्राफ़ में मौजूद सभी डिपेंडेंसी के सभी वर्शन को देखता है, ताकि हर डिपेंडेंसी का सबसे नया वर्शन तय किया जा सके. Gradle के बुनियादी टास्क और ज़्यादा बेहतर टूल का इस्तेमाल करके, यह पता लगाया जा सकता है कि Gradle ने हर डिपेंडेंसी के कौनसे वर्शन हल किए हैं. अपग्रेड के जोखिमों को समझने और कम करने के लिए, इस रिज़ॉल्यूशन में हुए बदलावों की तुलना करना ज़रूरी है.

उदाहरण के लिए, ./gradlew app:dependencies चलाकर Gradle dependencies टास्क का इस्तेमाल किया जा सकता है. इससे, आपके ऐप्लिकेशन मॉड्यूल में इस्तेमाल की गई सभी डिपेंडेंसी का ट्री दिखता है. दूसरे उदाहरण में, हमने लाइब्रेरी का इस्तेमाल करने वाले ऐप्लिकेशन पर इस विश्लेषण का इस्तेमाल किया है. इसमें हमें यह जानकारी मिली

1: releaseRuntimeClasspath - Runtime classpath of /release.
2: +--- org.jetbrains.kotlin:kotlin-stdlib:2.0.0
3: |    +--- ... (omitted for brevity) ...
4: +--- com.sample:library.a:1.2.3
5: |    +--- com.sample:library.c:2.1.1
6: |    |    \--- org.jetbrains.kotlin:kotlin-stdlib:2.0.0 (*)
7: |    \--- org.jetbrains.kotlin:kotlin-stdlib:2.0.0 (*)
8: +--- com.sample:library.c:1.4.1 -> 2.1.1 (*)

रिपोर्ट के इस हिस्से में, releaseRuntimeClasspath कॉन्फ़िगरेशन के लिए हल की गई कुछ डिपेंडेंसी दिखती हैं.

जब भी आपको अपनी डिपेंडेंसी रिपोर्ट में -> दिखता है, तो इसका मतलब है कि अनुरोध करने वाला (आपका ऐप्लिकेशन या कोई दूसरी लाइब्रेरी) उस डिपेंडेंसी के ऐसे वर्शन का इस्तेमाल कर रहा है जिसकी उसे उम्मीद नहीं थी. ज़्यादातर मामलों में, इससे कोई समस्या नहीं होती, क्योंकि ज़्यादातर लाइब्रेरी को पुराने सिस्टम के साथ काम करने के लिए लिखा जाता है. हालांकि, कुछ लाइब्रेरी में ऐसे बदलाव किए जा सकते हैं जो काम न करें. इस रिपोर्ट से, आपको यह पता लगाने में मदद मिल सकती है कि आपके ऐप्लिकेशन के काम करने के तरीके से जुड़ी नई समस्याएं कहां से आ रही हैं.

Gradle की डिपेंडेंसी रिपोर्टिंग का इस्तेमाल करने के बारे में ज़्यादा जानकारी पाने के लिए, डिपेंडेंसी देखना और डिबग करना लेख पढ़ें.

अनुरोध किए गए वर्शन की जानकारी, सीधे वर्शन कैटलॉग या बिल ऑफ़ मटीरियल (बीओएम) में दी जा सकती है.

डायरेक्ट वर्शन स्पेसिफ़िकेशन का रिज़ॉल्यूशन

आपने जो डिपेंडेंसी के वर्शन तय किए हैं वे वर्शन रिज़ॉल्यूशन के लिए उम्मीदवार बन जाते हैं.

उदाहरण के लिए, अपने app/build.gradle.kts में डिपेंडेंसी के तौर पर androidx.compose.ui:ui लाइब्रेरी के 1.7.3 वर्शन का अनुरोध करने के लिए:

dependencies {
    implementation("androidx.compose.ui:ui:1.7.3")
}

वर्शन 1.7.3, उम्मीदवार वर्शन बन जाता है. Gradle, ट्रांज़िटिव डिपेंडेंसी के अनुरोध पर, 1.7.3 और उसी लाइब्रेरी के अन्य वर्शन के बीच सबसे नए वर्शन को हल करता है.

वर्शन कैटलॉग का रिज़ॉल्यूशन

वर्शन कैटलॉग, आपके पूरे ऐप्लिकेशन में इस्तेमाल की गई डिपेंडेंसी के वर्शन को ट्रैक करने के लिए वैरिएबल तय करते हैं. अगर वर्शन कैटलॉग से किसी वैरिएबल का इस्तेमाल किया जाता है, तो उस वैरिएबल की तय की गई डिपेंडेंसी को वर्शन रिज़ॉल्यूशन के लिए उम्मीदवारों में जोड़ दिया जाता है. वर्शन कैटलॉग में इस्तेमाल नहीं किए गए वैरिएबल को अनदेखा कर दिया जाता है.

उदाहरण के लिए, अपनी gradle/libs.versions.toml फ़ाइल में androidx.compose.ui:ui के वर्शन 1.7.3 को डिपेंडेंसी के तौर पर बताने के लिए:

[versions]
ui = "1.7.3"

[libraries]
androidx-compose-ui = { group = "androidx.compose.ui", name = "ui", version.ref = "ui" }

यह लाइब्रेरी को दिखाने के लिए, libs.androidx.compose.ui नाम का एक वैरिएबल तय करता है. जब तक किसी डिपेंडेंसी के बारे में बताने के लिए उस वैरिएबल का इस्तेमाल नहीं किया जाता, तब तक इस वर्शन को उम्मीदवार के तौर पर नहीं माना जाता.

app/build.gradle.kts में लाइब्रेरी और उसके वर्शन का अनुरोध करने के लिए:

dependencies {
    implementation(libs.androidx.compose.ui)
}

Gradle, सीधे तौर पर बताए गए स्पेसिफ़िकेशन की तरह ही, इस स्पेसिफ़िकेशन को भी हल करता है.

बिल ऑफ़ मटीरियल (बीओएम) से जुड़ी समस्या का हल

BOM में दिखने वाली सभी लाइब्रेरी के वर्शन, वर्शन रिज़ॉल्यूशन के लिए उम्मीदवार बन जाते हैं. ध्यान दें कि लाइब्रेरी का इस्तेमाल डिपेंडेंसी के तौर पर सिर्फ़ तब किया जाता है, जब उन्हें डायरेक्ट या इनडायरेक्ट के तौर पर तय किया गया हो. BOM में मौजूद अन्य लाइब्रेरी को अनदेखा कर दिया जाता है.

BOM वर्शन का असर, आपकी डायरेक्ट डिपेंडेंसी के साथ-साथ BOM में दिखने वाली सभी ट्रांज़िशन डिपेंडेंसी पर पड़ता है.

उदाहरण के लिए, अपने app/build.gradle.kts में BOM को प्लैटफ़ॉर्म डिपेंडेंसी के तौर पर बताएं:

dependencies {
    implementation(platform("androidx.compose:compose-bom:2024.10.00"))
    implementation("androidx.compose.ui:ui")
}

जिन लाइब्रेरी का इस्तेमाल डिपेंडेंसी के तौर पर करना है उनके लिए वर्शन की जानकारी ज़रूरी नहीं है. अनुरोध किया गया वर्शन, बीओएम से मिलता है.

ध्यान दें कि BOM और लाइब्रेरी के लिए वैरिएबल बनाने के लिए, वर्शन कैटलॉग का भी इस्तेमाल किया जा सकता है. BOM डिपेंडेंसी में दिखने वाली लाइब्रेरी के लिए, वर्शन कैटलॉग में वर्शन नंबर शामिल न करें.

उदाहरण के लिए, आपके वर्शन कैटलॉग में BOM और उसका वर्शन नंबर शामिल है, लेकिन BOM से रेफ़र की गई लाइब्रेरी के लिए कोई वर्शन नहीं दिया गया है:

[versions]
composeBom = "2024.10.00"

[libraries]
androidx-compose-bom = { group = "androidx.compose", name = "compose-bom", version.ref = "composeBom" }
androidx-compose-ui = { group = "androidx.compose.ui", name = "ui" }

आपका app/build.gradle.kts, वर्शन कैटलॉग में तय किए गए वैरिएबल का इस्तेमाल करके, बीओएम और लाइब्रेरी का रेफ़रंस देता है:

dependencies {
    implementation(platform(libs.androidx.compose.bom))
    implementation(libs.androidx.compose.ui)
}

BOM में बताई गई लाइब्रेरी का वह वर्शन, Gradle के रिज़ॉल्यूशन के लिए एक उम्मीदवार बन जाता है. इसके अलावा, BOM में बताए गए लाइब्रेरी के सभी अन्य वर्शन, कैंडिडेट वर्शन बन जाते हैं. भले ही, आपने उन्हें सीधे तौर पर डिपेंडेंसी के तौर पर इस्तेमाल किया हो या नहीं.

उदाहरण के लिए, मान लें कि किसी BOM में लाइब्रेरी A, B, और C के वर्शन बताए गए हैं. आपका ऐप्लिकेशन, लाइब्रेरी A और लाइब्रेरी D, दोनों का इस्तेमाल डिपेंडेंसी के तौर पर करना चाहता है. लाइब्रेरी D, लाइब्रेरी B का इस्तेमाल डिपेंडेंसी के तौर पर करती है. लाइब्रेरी C का इस्तेमाल कोई नहीं करता.

लाइब्रेरी A, B, और D, ऐप्लिकेशन की डिपेंडेंसी हैं. लाइब्रेरी C को अनदेखा किया जाता है. Gradle, BOM में बताए गए A और B के वर्शन का इस्तेमाल, उम्मीदवारों के तौर पर करता है. भले ही, आपने लाइब्रेरी B को सीधे तौर पर डिपेंडेंसी के तौर पर न बताया हो.

अगर लाइब्रेरी D ने लाइब्रेरी B के 2.0.1 से पहले के वर्शन का अनुरोध किया है, तो Gradle 2.0.1 पर सेट हो जाती है. अगर लाइब्रेरी D ने लाइब्रेरी B के किसी नए वर्शन का अनुरोध किया है, तो Gradle उस वर्शन को हल करता है.