TechTargetは、Javaのビルドツール「Gradle」に関する記事を公開した。依存関係管理の問題への対処法をチュートリアル形式で紹介している。
2023年10月18日(米国時間)、TechTargetは「Gradle」に関する記事を公開した。
GradleはJavaのエコシステムの中でも人気のビルドツールだ。「Maven」と同じ様に、“慣例に基づいてビルドする”というアプローチができる上、「Make」や「Ant」のように、ビルドシステムの一部として任意の操作を実行できる「命令型」のビルドも選べる。
ただし注意点もある。Gradleを使う場合、「自分のビルドに対してどの程度の責任を負うのか」を慎重に選択する必要がある。Gradleの柔軟性は、サポートする開発チームの能力に依存するからだ。そこで本稿では、著者が遭遇した“依存関係管理の問題”を取り上げる。一般的で、保守が可能な、作業が簡単な方法に統合することで、対応しなければならない依存関係とそのバージョンの量を減らしてみようと思う。
なお、一言に“依存関係”と言ってもその範囲は広い。本稿で扱うのは「依存関係管理を一元化し、バージョンカタログを使用して他のプロジェクトに提供する方法」に関するものとする。
簡単な例を挙げる。「JUnit 5」のユニットテストフレームワークを使用する2つのプロジェクトがある。それぞれ「build.gradle.kts」ファイルがある。1つ目のプロジェクト(プロジェクト A)は以下のようになっている。
//プロジェクト A dependencies { implementation("com.mycorp:core-lib:1.19.0") testImplementation("org.junit.jupiter:junit-jupiter-api:5.9.3") testImplementation("org.junit.jupiter:junit-jupiter-engine:5.9.3") testImplementation("org.junit.jupiter:junit-jupiter-params:5.9.3") }
もう1つのプロジェクト(プロジェクト B)は恐らく最近できたもの(編集注:バージョンが新しいため)で、以下のようになっている。
//プロジェクト B dependencies { implementation("com.mycorp:core-lib:1.22.2") testImplementation("org.junit.jupiter:junit-jupiter-api:5.10.0") testImplementation("org.junit.jupiter:junit-jupiter-engine:5.10.0") testImplementation("org.junit.jupiter:junit-jupiter-params:5.10.0") }
この形は問題なく動作する。繰り返し“5.10.0”と記述するのを避けるため、以下のようにバージョン管理部分を外部化してもいいだろう。
// プロジェクト Bのバージョン管理を外部化する場合 val junitVersion = "5.10.0" dependencies { implementation("com.mycorp:core-lib:1.22.2") testImplementation("org.junit.jupiter:junit-jupiter-api:${junitVersion}") testImplementation("org.junit.jupiter:junit-jupiter-engine:${junitVersion}") testImplementation("org.junit.jupiter:junit-jupiter-params:${junitVersion}") }
ただ、“ベター”ではあるが“ベスト”ではない。プロジェクト Aには古い依存関係が残っているからだ。もちろんプロジェクト Aの該当するjUnitバージョンの値を更新すればいいのだが、その他の依存関係を持つバージョンを維持するのは負担がかかる。jUnitだけでなく、コアライブラリ(core-lib)のバージョンも更新する必要がある。
Copyright © ITmedia, Inc. All Rights Reserved.