קובצי ה-build מציינים את יחסי התלות הישירים, אבל כל אחד מהם עשוי לדרוש יחסי תלות אחרים. יחסי התלות העקיפים האלה גורמים להגדלה מהירה של תרשים יחסי התלות הכולל, ולעיתים קרובות יש בהם גרסאות סותרות.
כשהחלקים minor (תכונות חדשות) או patch (תיקוני באגים) משתנים, סביר להניח שהספרייה עדיין תהיה תואמת ויש פחות סיכוי שתהיה לכך השפעה על האפליקציה שלכם.
לדוגמה, נניח שהאפליקציה שלכם תלויה בספרייה א' ובספרייה ב', שתלויות בגרסאות שונות של ספרייה ג'.
במקרה כזה, Gradle בוחרת כברירת מחדל את הגרסה החדשה ביותר של ספרייה C, דבר שעלול לגרום לבעיות בהידור או בסביבת זמן הריצה. בדוגמה הזו, ספרייה ג' מוגדרת כ-2.1.1, אבל שימו לב שספרייה א' ביקשה את ספרייה ג' 1.0.3. החלק העיקרי של מספר הגרסה השתנה, מה שמעיד על שינויים לא תואמים, כמו פונקציות או סוגים שהוסרו. כתוצאה מכך, יכול להיות שקריאות שמבוצעות מספרייה א' יקרסו.
לאפליקציה שלך יכולות להיות יחסי תלות ישירים, שהם גם יחסי תלות זמניים.
במקרה כזה, יחסי תלות חדשים יותר יכולים לבטל את הגרסה שביקשתם ישירות באפליקציה.
Gradle בודק את כל הגרסאות האפשריות לכל יחסי התלות בתרשים כדי לקבוע את הגרסה העדכנית ביותר של כל יחסי התלות. אפשר להשתמש במשימות Gradle בסיסיות ובכלים מתקדמים יותר כדי לקבוע אילו גרסאות של כל יחסי התלות Gradle פתר. השוואת השינויים ברזולוציה הזו היא חיונית להבנה ולצמצום של הסיכונים בשדרוג.
לדוגמה, אפשר להשתמש במשימה dependencies של Gradle על ידי הפעלת ./gradlew
app:dependencies כדי להציג עץ של כל יחסי התלות שבהם משתמש מודול האפליקציה. כשמריצים את הבדיקה הזו באפליקציה שמשתמשת בספריות כפי שמוצג באיור 2, מופיע
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 זמינים במאמר הצגה וניפוי באגים של יחסי התלות.
אפשר לציין את הגרסאות המבוקשות ישירות בקטלוג גרסאות או ב-Bill of Materials (BOM).
פתרון ישיר של הגדרת הגרסה
הגרסאות של יחסי התלות שציינתם הופכות למועמדות לפתרון בעיות בגרסאות.
לדוגמה, כדי לבקש את גרסה 1.7.3 של הספרייה androidx.compose.ui:ui כתלות ב-app/build.gradle.kts:
dependencies {
implementation("androidx.compose.ui:ui:1.7.3")
}
גרסה 1.7.3 הופכת לגרסה מועמדת. Gradle פותר את הגרסה העדכנית ביותר מבין 1.7.3 וגרסאות אחרות של אותה ספרייה שנדרשות על ידי יחסי תלות טרנזיטיביים.
רזולוציית קטלוג הגרסאות
קטלוגים של גרסאות מגדירים משתנים למעקב אחרי הגרסה של יחסי התלות שבהם נעשה שימוש באפליקציה. אם משתמשים במשתנה מקטלוג הגרסאות, יחסי התלות שצוינו בו נוספים למועמדים לרזולוציית הגרסה. המערכת מתעלמת ממשתנים שלא בשימוש בקטלוג הגרסאות.
לדוגמה, כדי לציין את גרסה 1.7.3 של androidx.compose.ui:ui כתלות בקובץ gradle/libs.versions.toml:
[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 פותר את הבעיה באותו אופן שבו הוא פותר אותה עבור מפרט ישיר.
הרזולוציה של Bill of Materials (BOM)
הגרסאות של כל הספריות שמופיעות ב-BOM הופכות למועמדות לפתרון בעיות בגרסאות. חשוב לזכור שנעשה שימוש בספריות כיחסי תלות רק אם הן צוינו כיחסי תלות ישירים או עקיפים. המערכת מתעלמת מספריות אחרות ב-BOM.
גרסאות ה-BOM משפיעות על יחסי התלות הישירים וגם על כל יחסי התלות הטרנזיטיביים שמופיעים ב-BOM.
לדוגמה, מציינים BOM כיחס תלות מסוג platform בקובץ app/build.gradle.kts:
dependencies {
implementation(platform("androidx.compose:compose-bom:2024.10.00"))
implementation("androidx.compose.ui:ui")
}
בספריות שרוצים להשתמש בהן כיחסי תלות לא נדרש מפרט גרסה. הגרסה המבוקשת מגיעה מה-BOM.
הערה: אפשר גם להשתמש בקטלוג גרסאות כדי ליצור משתנים ל-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 מפנה ל-BOM ולספריות באמצעות המשתנים שהוגדרו בקטלוג הגרסאות:
dependencies {
implementation(platform(libs.androidx.compose.bom))
implementation(libs.androidx.compose.ui)
}
גרסת הספרייה הזו שצוינה ב-BOM הופכת למועמדת לרזולוציה של Gradle. בנוסף, כל גרסאות הספרייה האחרות שצוינו ב-BOM יהפכו לגרסאות מועמדים, גם אם לא משתמשים בהן באופן ישיר כיחסי תלות וגם אם לא.
לדוגמה, נניח שב-BOM מצוינות גרסאות לספריות A, B ו-C. האפליקציה שלכם רוצה להשתמש באופן ישיר בספרייה א' כתלות, וגם בספרייה ד'. ספרייה ד' משתמשת בספרייה ב' כתלות. אף אחד לא משתמש בספרייה C.
ספריות A, B ו-D הן יחסי תלות באפליקציה ומתעלמים מספרייה C. Gradle משתמשת בגרסאות של A ו-B שצוינו ב-BOM כמועמדים, למרות שלא ציינת התלות באופן ישיר של ספרייה B.
אם ספרייה D ביקשה גרסה של ספרייה B שקדמה ל-2.0.1, Gradle יפתור את הבעיה ויגדיר את הגרסה כ-2.0.1. אם ספרייה D ביקשה גרסה גבוהה יותר של ספרייה B, אז Gradle מגיבה לגרסה הזו.