लेख 5 : libs.versions.toml साझा का रोमांच

----
tasks.register<JavaExec>("bake") {
    mainClass.set("org.jbake.launcher.Main")
    classpath = configurations["jbake"]
    args = listOf(projectDir.absolutePath, "$buildDir/jbake")
}**कहाँ एक स्वतंत्र बिल्ड (हमारा प्लगिन) को दूसरे में शामिल किया जाना चाहिए ?

यह वही जगह थी जहाँ हमारी यात्रा ने अप्रत्याशित मोड़ ले लिया। हम चाहते थे कि हमारा प्लगइन`site-baker`, जो स्वयं एक Gradle प्रोजेक्ट है, हमारे मुख्य प्रोजेक्ट के समान संस्करण कैटलॉग का उपयोग करता है। यह लेख, हमारी श्रृंखला का पाँचवाँ, बताता है कि हमने इस चुनौती को कैसे हल किया।

== 1. वर्ज़न कैटलॉग (`libs.versions.toml`) : एक अनुस्मरण

फ़ाइल`gradle/libs.versions.toml`यह Gradle की एक सुविधा है जो आपके परियोजना के निर्भरताओं के संस्करण और निर्देशांक को केंद्रीकृत करने की अनुमति देती है। इसकी सामान्य रूप से चार खंडों में संरचना होती है:

*   `[versions]`: परिभाषित करता है संस्करण संख्याओं के लिए एलियास (उदाहरण:`kotlin = "1.9.20"`).
*   `[libraries]`: परिभाषित करता है अलियास पूर्ण निर्भरताओं के लिए, ऊपर परिभाषित संस्करणों का उपयोग करके (ex:`kotlin-stdlib = { module = "org.jetbrains.kotlin:kotlin-stdlib", version.ref = "kotlin" }`).
*   `[bundles]`कई लाइब्रेरीज़ को एक ही एलियास के तहत समूहित करता (उदाहरण:`jackson = ["jackson-core", "jackson-databind"]`)
*   `[plugins]`: ग्रैडल प्लगिन के लिए एलियास परिभाषित करता है।

एक बार परिभाषित करने पर, Gradle स्वचालित रूप से टाइप किए हुए एक्सेसर उत्पन्न करता है, जिससे आपका`build.gradle.kts` beaucoup plus lisible :

[source,kotlin]
----
dependencies {
    // Au lieu de : implementation("org.jetbrains.kotlin:kotlin-stdlib:1.9.20")
    implementation(libs.kotlin.stdlib)
}
----

.संस्करण कैटलॉग का डेटा प्रवाह

[plantuml, toml-flow, svg]
----
@startuml
!theme plain
file "gradle/libs.versions.toml" as Toml
node "ग्रैडल" as G
file "build.gradle.kts" as BuildScript

Toml --> G : "द्वारा पढ़ा जाता है"
G --> BuildScript : "एक्सेसर `libs` जेनरेट करें"
BuildScript -> G : "libs` का उपयोग करके निर्भरताओं की घोषणा करें"
@enduml
----

== 2. समस्या: एक संयुक्त बिल्ड और दो अलग‑अलग दुनियाएँ

हमारी परियोजना संरचना एक**JBake को Gradle बिल्ड में JBake Gradle प्लगइन का उपयोग करके या JBake CLI को सीधे कॉल करके एकीकृत किया जा सकता है:

----

tasks.register<JavaExec>("bake") { mainClass.set("org.jbake.launcher.Main") classpath = configurations["jbake"] args = listOf(projectDir.absolutePath, "$buildDir/jbake") }**. मुख्य परियोजना (`thymeleaf.cheroliv.com`) inclut le projet du plugin (`site-baker`) के माध्यम से आदेश`includeBuild("site-baker")`फ़ाइल में`settings.gradle.kts`.

.build composite की संरचना

[plantuml, composite-build, svg]
----
@startuml
!theme plain
package "मुख्य परियोजना" {
  file "settings.gradle.kts" as MainSettings
  folder "gradle" {
    file "libs.versions.toml" as MainToml
  }
}

package "### ग्रैडल एकीकरण
JBake को JBake ग्रैडल प्लगइन का उपयोग करके या JBake CLI को सीधे कॉल करके ग्रैडल बिल्ड में एकीकृत किया जा सकता है:

```kotlin
tasks.register<JavaExec>("bake") {
    mainClass.set("org.jbake.launcher.Main")
    classpath = configurations["jbake"]
    args = listOf(projectDir.absolutePath, "$buildDir/jbake")
}" {
  file "settings.gradle.kts" as PluginSettings
  file "build.gradle.kts" as PluginBuild
}

MainSettings -> PluginSettings : `includeBuild("स्थान-बेकर")`
PluginBuild ..> MainToml : **Voulait accéder à...**
note right on link: ...mais ne pouvait pas !
@enduml
----

समस्या यह है कि, डिफ़ॉल्ट रूप से, एक शामिल बिल्ड एक है**अलग दुनिया**. इसकी अपनी कॉन्फ़िगरेशन, इसका अपना जीवन चक्र, और यह फ़ाइल को नहीं देखता`libs.versions.toml`मुख्य बिल्ड का. हमारा`plugin/build.gradle.kts`उपयोग करने की कोशिश कर रहा था`libs.plugins.kotlin.jvm`, लेकिन वस्तु`libs`सही TOML फ़ाइल से उत्पन्न नहीं किया गया था, जिससे बिल्ड त्रुटियाँ हुईं।

== 3. समाधान : निर्भरता समाधान साझा करना

कई शोधों के बाद, यह समाधान Gradle की एक ऐसी विशेषता निकली जो इस मामले के लिए विशेष रूप से डिज़ाइन की गई थी :`dependencyResolutionManagement`.

फ़ाइल में`settings.gradle.kts` du **समावेशी निर्माण**import sys

def main(): data = sys.stdin.read() sys.stdout.write(data)

if __name__ == '__main__': main()`site-baker/settings.gradle.kts`), हम Gradle को बता सकते हैं कि संस्करण कैटलॉग कहाँ से उपयोग करने के लिए प्राप्त किया जा सकता है।

यहाँ वह कॉन्फ़िगरेशन है जिसे हमने जोड़ा है`site-baker/settings.gradle.kts`:

[source,kotlin]
----
// 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")
----

महत्वपूर्ण भाग का विश्लेषण करें:

[source,kotlin]
----
versionCatalogs {
    create("libs") { // Crée un catalogue nommé 'libs'
        from(files("../gradle/libs.versions.toml")) // En utilisant ce fichier
    }
}
----

*   `create("libs")`: हम संस्करणों का एक कैटलॉग घोषित करते हैं जिसे लियास के माध्यम से पहुँचा जा सकेगा`libs`.
*   `from(files("../gradle/libs.versions.toml"))`: यह जादू है। हम Gradle को बताते हैं कि इस कैटलॉग का स्रोत TOML फ़ाइल निर्देशिका में स्थित है।`gradle` du **मातृ परियोजना**(No output)`../`)

इस कॉन्फ़िगरेशन के साथ, बिल्ड`site-baker`अब उसे पता है कि उसे मुख्य प्रोजेक्ट के संस्करण कैटलॉग का उपयोग करना होगा। वस्तु`libs`सही ढंग से उत्पन्न किया गया है, और निर्भरताएँ अपेक्षित रूप से समाधान कर ली गई हैं।

== 4. निष्कर्ष : अच्छी तरह से प्रबंधित संयुक्त निर्माणों की शक्ति

यह अनुभव सीखों से भरपूर रहा। संस्करण कैटलॉग रखरखाव के लिए एक शानदार उपकरण है, लेकिन कंपोज़िट बिल्ड परिदृश्यों में उसका व्यवहार हमेशा सहज नहीं होता।

की याद रखनी है कि एक समावेशी बिल्ड एक स्वतंत्र बिल्ड ही रहता है। संस्करण कैटलॉग जैसी कॉन्फ़िगरेशन साझा करने के लिए, Gradle द्वारा प्रदान किए गए स्पष्ट तंत्र का उपयोग करना आवश्यक है, जैसे ब्लॉक।`dependencyResolutionManagement`में`settings.gradle.kts`.

इस समस्या को हल करके, हमने न केवल अपने build को साफ़ किया, बल्कि हमने अपने प्रोजेक्ट की स्थिरता को भी मजबूत किया है, यह सुनिश्चित करके कि प्लगइन और मुख्य प्रोजेक्ट एक ही स्रोत की सच्चाई साझा करते हैं अपने dependencies के लिए।

अगले आर्टिकल में, हम अब अधिक जटिल कार्य जोड़कर अपने प्लगइन को समृद्ध करना जारी रखेंगे, क्योंकि अब हमारी निर्भरता प्रबंधन मजबूत और केंद्रीकृत है।