�Άρθρο 5 : Η Περιπέτεια του libs.versions.toml Κοινόχρηστο
Publié le 27 September 2025
Εισαγωγή
Στην αναζητήση μας για τη δημιουργία του plugin`site-baker`, έχουμε προσπαθήσει να διατηρήσουμε μια καθαρή και κεντρική βάση κώδικα. Μία από τις καλύτερες πρακτικές στο σύγχρονο οικοσύστημα Gradle είναι η χρήση τουκατάλογος εκδόσεων(libs.versions.toml) για να διαχειριστείτε τις εξαρτήσεις. Αλλά τι συμβαίνει когда το έργο σας γίνεται πιο πολύπλοκο, όπως ένανα χτίσουμε σύνθετοoù ένα ανεξάρτητο build (το plugin μας) πρέπει να συμπεριληφθεί σε ένα άλλο?
Εδώ η περιπέτειά μας πήρε μια απροσδόκητη στροφή. Θέλνα το plugin μας.site-baker, που είναι ίδιο το Gradle project, χρησιμοποιεί το ίδιο κατάλογο εκδόσεων με το κύριο project μας. Αυτό το άρθρο, το πέμπτο της σειράς μας, λέει πώς λύσαμε αυτήν τη πρόκληση.
Ο Κατάλογος Εκδόσεων (libs.versions.toml) : Μια υπενθύμιση
Το αρχείο`gradle/libs.versions.toml`είναι μια λειτουργία του Gradle που επιτρέπει την κεντρική διαχείριση των εκδόσεων και των συντεταγμένων των εξαρτήσεων του έργου σας. Συνήθως είναι δομημένο σε τέσσερις ενότητες :
-
[versions]: Ορίζει ψευδώνυμα για τους αριθμούς εκδόσεων (π.χ.kotlin = "1.9.20"). -
[libraries]: Ορίζει ψευδώνυμα για τις πλήρεις εξαρτήσεις, χρησιμοποιώντας τις εκδόσεις που ορίστηκαν παραπάνω (π.χ.kotlin-stdlib = { module = "org.jetbrains.kotlin:kotlin-stdlib", version.ref = "kotlin" }) -
[bundles]: Ομαδοποιεί διάφορες βιβlioθήκες υπό ένα μόνο ψευδώνυμο (πχ:`jackson = ["jackson-core", "jackson-databind"]`). -
[plugins]: Ορίζει ψευδώνυμα για τα πρόσθετα Gradle.
Μια φορά που ορίζεται, o Gradle δημιουργεί αυτόματα τύπους προσβασιμότητας, κάνοντάς το`build.gradle.kts`πολύ πιο ευάνγνωστο :
dependencies {
// Au lieu de : implementation("org.jetbrains.kotlin:kotlin-stdlib:1.9.20")
implementation(libs.kotlin.stdlib)
}
2. Το πρόβλημα: Ένας σύνθετος Build και δύο χωρισμένοι κόσμοι
Η δομή του έργου μας είναι έναΧτίστε το σύνθετο. Το κύριο έργο (thymeleaf.cheroliv.com) περιλαμβάνει το έργο του plugin (site-baker) μέσω της εντολής`includeBuild("site-baker")στο αρχείο`settings.gradle.kts.
Το πρόβλημα είναι ότι, προεπιλογώς, ένα build που συμπεριλαμβάνεται είναι έναδιαχωρισμΈνος κόσμος. Έχει τη δική του ρύθμιση, το δικό του κύκλο ζωής, και δεν βλέπει το αρχείο`libs.versions.toml`Η κύρια κατασκευή. Το δικό μας`plugin/build.gradle.kts`προσπαθούσε να το χρησιμοποιήσει`libs.plugins.kotlin.jvm`, αλλά το αντικείμενο`libs`Δεν δημιούργησε από το σωστό αρχείο TOML, προκαλώντας σφάλματα κατασκευής.
3. Η Λύση : Κοινόχρηστη επίλυση εξαρτήσεων
Μετά από πολλές έρευνες, η λύση αποδείχθηκε ότι είναι μια λειτουργικότητα του Gradle που σχεδιάστηκε ειδικά για αυτή τη περίπτωση:`dependencyResolutionManagement`.
Στο αρχείο`settings.gradle.kts` du κατασκευή συμπεριλαμβανομένη(site-baker/settings.gradle.kts), μπορούμε να πούμε στο Gradle πού να βρει τον κατάλογο εκδόσεων που θα χρησιμοποιηθεί.
Εδώ είναι η ρύθμιση που προσθέσαμε σε`site-baker/settings.gradle.kts` :
// site-baker/settings.gradle.kts
dependencyResolutionManagement {
repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
repositories {
gradlePluginPortal()
mavenCentral()
}
versionCatalogs {
create("libs") {
from(files("../gradle/libs.versions.toml"))
}
}
}
rootProject.name = "site-baker"
include("plugin")Αναλύουμε την κρίσιμη ενότητα:
versionCatalogs {
create("libs") { // Crée un catalogue nommé 'libs'
from(files("../gradle/libs.versions.toml")) // En utilisant ce fichier
}
}-
create("libs"): Δηλώνουμε έναν κατάλογο εκδόσεων που θα είναι προσβάσιμος μέσω του alias`libs`. -
from(files("../gradle/libs.versions.toml")): Αυτό είναι η μαγεία. Ενημερώνουμε το Gradle ότι η πηγή αυτού του καταλόγου είναι το αρχείο TOML που βρίσκεται στον κατάλογο.gradledu γονικό έργο(empty)../)
Με αυτή τη ρύθμιση, η κατασκευή`site-baker`�Ξέρει τώρα ότι πρέπει να χρησιμοποιήσει τον κατάλογο εκδόσεων του κύριου έργου. Το αντικείμενο`libs`γεννείται σωστά, και οι εξαρτήσεις είναι λυμένες όπως περίμενα.
4. Συμπέρασμα: Η δύναμη των καλά διαχειριζόμενων συνθέτικών κατασκευών
Αυτή η εμπειρία ήταν πλούσια σε διδακτικά. Ο κατάλογος εκδόσεων είναι ένα εξαιρετικό εργαλείο για τη συντηρησιμότητα, αλλά η συμπεριballe του σε σενάρια σύνθετων κατασκευών δεν είναι πάντα intuïtικη.
Η κλειδί είναι να θυμάσαι ότι ένα build που περιλαμβάνεται παραμένει ανεξάρτητο build. Για να μοιραστείς τις ρυθμίσεις όπως το κατάλογο εκδόσεων, πρέπει να χρησιμοποιήσεις τις ρητές μηχανισμούς που παρέχονται από το Gradle, όπως το block`dependencyResolutionManagement`σε`settings.gradle.kts`.
Λύνοντας αυτό το πρόβλημα, δεν μόνο καθαρίσαμε τη διαδικασία δημιουργίας μας, αλλά και ενισχύσαμε τη συνέπεια του έργου μας, βεβαιωθείς ότι το πρόσθετο και το κύριο έργο μοιράζονται μία μοναδική πηγή αλήθειας για τις εξαρτήσεις τους.
Στον επόμενο άρθρο, θα συνεχίσουμε να ενισχύουμε το plugin μας προσθέτοντας πιο σύνθετες εργασίες, επειδή η διαχείριση των εξαρτήσεων μας είναι τώρα σταθερή και κεντραλισμένη.