Mavenで最新バージョンの依存関係を使用する
1. 概要
Mavenの依存関係を手動でアップグレードすることは、特に多くのライブラリが頻繁にリリースされるプロジェクトでは特に面倒な作業でした。
このチュートリアルでは、how to exploit the Versions Maven Plugin to keep our dependencies up-to-dateを学習します。
とりわけ、これは、依存関係を自動的にアップグレードし、すべてが適切に動作することをテストし、結果をコミットまたはロールバックする適切な方法で継続的インテグレーションパイプラインを実装する場合に非常に役立ちます。
2. Mavenバージョン範囲の構文
Maven2の時代に戻ると、開発者は、手動による介入を必要とせずに、アーティファクトがアップグレードされるバージョン範囲を指定できました。
この構文はまだ有効であり、世の中のいくつかのプロジェクトで使用されているため、知っておく価値があります。
それにもかかわらず、可能な場合はVersions Mavenプラグインを優先して回避する必要があります。外部から具体的なバージョンを進めると、Mavenが単独で操作全体を処理するよりも確実に多くの制御ができるからです。
2.1. 非推奨の構文
Maven2は、結果を達成するために、LATESTとRELEASEという2つの特別なメタバージョン値も提供しました。
However, this legacy upgrade method was causing unpredictability where CI needed reproducibility.したがって、Maven3のthey’ve been deprecated and completely removed:
再現可能なビルドのために、Maven 3.xはPOMでこれらのメタバージョンの使用をサポートしなくなりました
3. バージョンMavenプラグイン
Versions Maven Pluginは、現在のバージョン管理を処理するための事実上の標準的な方法です。
SNAPSHOTバージョンのリモートリポジトリ間の高レベルの比較から低レベルのタイムスタンプロックまで、その膨大な目標リストにより、依存関係を含むプロジェクトのあらゆる側面を処理できます。
それらの多くはこのチュートリアルの範囲外ですが、アップグレードプロセスで役立つものを詳しく見ていきましょう。
3.1. テストケース
始める前に、テストケースを定義しましょう。
-
ハードコーディングされたバージョンの3つのリリース
-
プロパティバージョンを含む1つのリリース
-
1つのスナップショット
commons-io
commons-io
2.3
org.apache.commons
commons-collections4
4.0
org.apache.commons
commons-lang3
3.0
org.apache.commons
commons-compress
${commons-compress-version}
commons-beanutils
commons-beanutils
1.9.1-SNAPSHOT
1.15
最後に、プラグインを定義するときに、プロセスからアーティファクトを除外しましょう。
org.codehaus.mojo
versions-maven-plugin
2.7
org.apache.commons:commons-collections4
4. 利用可能なアップデートの表示
まず第一に、to simply know if and how we can update our project, the right tool for the job is versions:display-dependency-updates:
mvn versions:display-dependency-updates
ご覧のとおり、the process included every RELEASE version. It even included commons-collections4 since the exclusion in the configuration refers to the update process, and not to the discovery one.
対照的に、SNAPSHOTは開発バージョンであり、自動的に更新するのが安全でないことが多いため、SNAPSHOTを無視しました。
5. 依存関係の更新
初めて更新を実行するとき、プラグインはpom.xml.versionsBackupという名前のpom.xmlのバックアップを作成します。
すべての反復でpom.xmlが変更されますが、バックアップファイルは、ユーザーがコミットする(mvn versions:commitを介して)か元に戻す(mvn versions:revertを介して)まで、プロジェクトの元の状態を保持します。プロセス全体。
5.1. SNAPSHOTをRELEASEに変換する
プロジェクトにSNAPSHOT(まだ開発中のバージョン)が含まれている場合があります。
versions:use-releasesを使用して、対応するRELEASEが公開されているかどうかを確認できます。さらに、SNAPSHOTを同時にそのRELEASEに変換することもできます。
mvn versions:use-releases
5.2. 次のリリースへの更新
We can port every non-SNAPSHOT dependency to its nearest versionとversions:use-next-releases:
mvn versions:use-next-releases
プラグインがcommons-io、commons-lang3、さらにはスナップショットではなくなったcommons-beanutilsを次のバージョンに更新したことがはっきりとわかります。
最も重要なことは、プラグイン構成で除外されているcommons-collections4と、プロパティを通じて動的に指定されたバージョン番号を持つcommons-compressを無視したことです。
5.3. 最新のリリースへの更新
SNAPSHOT以外のすべての依存関係を最新リリースに更新することも同じように機能し、目標をversions:use-latest-releasesに変更するだけです。
mvn versions:use-latest-releases
6. 不要なバージョンの除外
In case we want to ignore certain versions, the plugin configuration can be tunedは、外部ファイルからルールを動的にロードします。
org.codehaus.mojo
versions-maven-plugin
2.7
http://www.mycompany.com/maven-version-rules.xml
最も注目に値するのは、<rulesUri>がローカルファイルを参照することもできることです。
file:///home/andrea/maven-version-rules.xml
6.1. バージョンをグローバルに無視する
it’ll ignore versions matching a specific Regular Expressionが次のようになるようにルールファイルを構成できます。
.*-beta
6.2. ルールごとのバージョンの無視
最後に、ニーズがより具体的な場合、代わりに一連のルールを作成できます。
.*-RELEASE
2.1.0
7. 結論
安全で自動のMaven3準拠の方法で、プロジェクトの依存関係を確認および更新する方法を見てきました。
いつものように、ソースコードはover on GitHubで利用でき、スクリプトはすべてを段階的に、複雑にすることなく紹介するのに役立ちます。
動作を確認するには、プロジェクトをダウンロードしてターミナルで実行します(Windowsを使用している場合はGit Bashで実行します):
./run-the-demo.sh