第5条：共有された libs.versions.toml の冒険
公開日: 27 September 2025
はじめに
プラグインを作るための私たちの探求の中で`site-baker`私たちはクリーンで集中されたコードベースを維持しようと努めてきました。現代のGradleエコシステムにおけるベストプラクティスの一つは、の使用ですバージョンカタログ (libs.versions.toml) で依存関係を管理するために。 しかし、プロジェクトがより複雑になるとどうなるでしょうか、例えば複合をビルドここで、独立したビルド（私たちのプラグイン）は他のものに含めなければなりませんか？
そこが私たちの冒険が思いがけない転機を迎えた場所だった。私たちは私たちのプラグインが`site-baker`, それ自体が Gradle プロジェクトである、私たちのメインプロジェクトと同じバージョン カタログを使用します。 この記事は、私たちのシリーズの第五回目で、その課題をどのように解決したかを説明しています。
1. バージョンカタログ (libs.versions.toml) : リマインダー
ファイル`gradle/libs.versions.toml`Gradleの機能で、プロジェクトの依存関係のバージョンと座標を一元管理することができます。通常、4つのセクションに構成されています：
-
[versions]: バージョン番号のエイリアスを定義します (例:`kotlin = "1.9.20"`). -
[libraries]: 完全な依存関係のエイリアスを設定します。上で定義したバージョンを使用します（例:`kotlin-stdlib = { module = "org.jetbrains.kotlin:kotlin-stdlib", version.ref = "kotlin" }`) -
[bundles]`複数のライブラリを単一のエイリアスにグループ化（例：`jackson = ["jackson-core", "jackson-databind"]). -
`[plugins]`Gradle プラグインのエイリアスを定義します。
定義すると、Gradle は自動的に型付きアクセッサを生成し、これによりあなたの`build.gradle.kts`ずっと読みやすい :
dependencies {
// Au lieu de : implementation("org.jetbrains.kotlin:kotlin-stdlib:1.9.20")
implementation(libs.kotlin.stdlib)
}@startuml !theme plain file "gradle/libs.versions.toml" as Toml node "Gradle" as G file "build.gradle.kts" as BuildScript Toml --> G : "によって読まれている" G --> BuildScript : "アクセッサを生成 `libs" BuildScript -> G : "libs` を使用して 依存関係を宣言する" @enduml
2. 問題：複合ビルドと二つの別々な世界
私たちのプロジェクト構造はビルド コンポジット. 主要なプロジェクト (thymeleaf.cheroliv.com) プラグインのプロジェクトを含む (site-baker) コマンド経由で`includeBuild("site-baker")ファイルの中に`settings.gradle.kts。
@startuml
!theme plain
package "主要プロジェクト" {
file "settings.gradle.kts" as MainSettings
folder "グレードル" {
file "libs.versions.toml" as MainToml
}
}
package "プラグイン `site-baker` (Build Inclus)" {
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` n’était pas généré à partir du bon fichier TOML, provoquant des erreurs de build.
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"): 私たちは、エイリアスを通じてアクセスできるバージョンのカタログを宣言します。libs. -
from(files("../gradle/libs.versions.toml")): これが魔法です。 私たちはGradleに、このカタログのソースがこのディレクトリ内にあるTOMLファイルであることを伝えます。gradledu 親プロジェクト(../“).”
この設定では、ビルド`site-baker`彼は今、メインプロジェクトのバージョンカタログを使用しなければならないことを知っている。オブジェクト`libs`正しく生成され、依存関係は予定通りに解決されます。
4. 結論：適切に管理されたコンポジットビルドの力
この経験は多くの教訓を得るものでした。バージョンカタログは保守性に優れた素晴らしいツールですが、複合ビルドシナリオでのその動作は必ずしも直感的ではありません。
ポイントは、インクルードされたビルドでも独立したビルドのままであることを覚えておくことです。バージョンカタログのような設定を共有するには、Gradleが提供する明示的なメカニズム、例えばブロックを使用する必要があります。dependencyResolutionManagement`中`settings.gradle.kts.
この問題を解決することで、私たちのビルドをきれいにするだけでなく、プラグインとメインプロジェクトが依存関係について唯一の真実のソースを共有することを確認することで、プロジェクトの一貫性も強化しました。
次の記事では、依存関係の管理が堅牢かつ集中化された今、さらに複雑なタスクを追加することでプラグインを充実させていきます。
関連記事
31 May 2026
14 May 2026