Mavenで最新バージョンの依存関係を使用する

投稿日: 2019-10-18 2022-10-31
タグ: Maven

1. 概要

Mavenの依存関係を手動でアップグレードすることは、特に多くのライブラリが頻繁にリリースされるプロジェクトでは、常に退屈な作業でした。

このチュートリアルでは、バージョンMavenプラグインを活用して、依存関係を最新の状態に保つ方法を学習します。

とりわけ、これは、依存関係を自動的にアップグレードし、すべてが引き続き正しく機能することをテストし、結果をコミットまたはロールバックする、適切な方の継続的インテグレーションパイプラインを実装する場合に非常に役立ちます。

2. Mavenバージョン範囲構文

Maven2の時代には、開発者は手動の介入を必要とせずにアーティファクトがアップグレードされるバージョン範囲を指定できました。

この構文はまだ有効であり、いくつかのプロジェクトで使用されているため、知っておく価値があります。

それでも、可能な場合はVersions Mavenプラグインを優先して回避する必要があります。これは、具体的なバージョンを外部から進めることで、Mavenに操作全体を単独で処理させるよりも確実に制御できるためです。

2.1. 非推奨の構文

Maven2は、結果を達成するために、LATESTとRELEASEという2つの特別なメタバージョン値も提供しました。

LATEST は可能な限り最新のバージョンを探し、RELEASEは最新の非SNAPSHOTバージョンを目指します。

確かに、それらは通常の依存関係の解決に対してまだ絶対的に有効です。

ただし、このレガシーアップグレード方法は、CIが再現性を必要とする場合に予測不可能性を引き起こしていました。したがって、プラグインの依存関係の解決のために非推奨になりました。

3. バージョンMavenプラグイン

Versions Mavenプラグインは、現在のバージョン管理を処理するための事実上の標準的な方法です。

リモートリポジトリ間の高レベルの比較からSNAPSHOTバージョンの低レベルのタイムスタンプロックまで、その膨大な目標リストにより、依存関係を含むプロジェクトのあらゆる側面を処理できます。

それらの多くはこのチュートリアルの範囲外ですが、アップグレードプロセスで役立つものを詳しく見ていきましょう。

3.1. テストケース

始める前に、テストケースを定義しましょう。

ハードコードされたバージョンの3つのリリース
プロパティバージョンを含む1つのリリース、および
1つのスナップショット

<dependencies>
    <dependency>
        <groupId>commons-io</groupId>
        <artifactId>commons-io</artifactId>
        <version>2.3</version>
    </dependency>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-collections4</artifactId>
        <version>4.0</version>
    </dependency>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-lang3</artifactId>
        <version>3.0</version>
    </dependency>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-compress</artifactId>
        <version>${commons-compress-version}</version>
    </dependency>
    <dependency>
        <groupId>commons-beanutils</groupId>
        <artifactId>commons-beanutils</artifactId>
        <version>1.9.1-SNAPSHOT</version>
    </dependency>
</dependencies>

<properties>        
    <commons-compress-version>1.15</commons-compress-version>
</properties>

最後に、プラグインを定義するときに、プロセスからアーティファクトも除外しましょう。

<build>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>versions-maven-plugin</artifactId>
            <version>2.7</version>
            <configuration>
                <excludes>
                    <exclude>org.apache.commons:commons-collections4</exclude>
                </excludes>
            </configuration>
        </plugin>
    </plugins>
</build>

4. 利用可能なアップデートの表示

まず、プロジェクトを更新できるかどうか、またどのように更新できるかを簡単に知るために、このジョブに適したツールはversions：display-dependency-updatesです。

mvn versions:display-dependency-updates

ご覧のとおり、プロセスには、すべてのRELEASEバージョンが含まれていました。構成での除外は更新プロセスを参照し、検出プロセスを参照しないため、commons-collections4も含まれています。

対照的に、SNAPSHOTは開発バージョンであり、自動的に更新するのは安全ではないことが多いため、SNAPSHOTは無視されました。

5. 依存関係の更新

プラグインは、初めて更新を実行するときに、pom.xml.versionsBackupという名前のpom.xmlのバックアップを作成します。

反復ごとにpom.xmlが変更されますが、バックアップファイルは、ユーザーがコミットする（ mvn version：commit を介して）か元に戻すまで、プロジェクトの元の状態を保持します。（ mvn version：revert を介して）プロセス全体。

5.1. SNAPSHOTをRELEASEに変換する

プロジェクトにSNAPSHOT（まだ開発中のバージョン）が含まれている場合があります。

versions：use-releases を使用して、対応するRELEASEが公開されているかどうかを確認できます。さらに、SNAPSHOTを同時にそのRELEASEに変換することもできます。

mvn versions:use-releases

5.2. 次のリリースへの更新

SNAPSHOT以外のすべての依存関係を、 version：use-next-releasesを使用して最も近いバージョンに移植できます。

mvn versions:use-next-releases

プラグインがcommons-io、 commons-lang3 、さらにはSNAPSHOTではなくなったcommons-beanutilsを次のプラグインに更新したことがはっきりとわかります。バージョン。

最も重要なことは、プラグイン構成で除外されている c ommons-collections4 と、バージョン番号が動的に指定されているcommons-compressを無視したことです。財産。

5.3. 最新のリリースに更新

SNAPSHOT以外のすべての依存関係を最新リリースに更新することも同じように機能し、目標を versions：use-latest-releasesに変更するだけです。

mvn versions:use-latest-releases

6. 不要なバージョンの除外

特定のバージョンを無視したい場合は、プラグイン構成を調整して、外部ファイルからルールを動的にロードできます。

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>versions-maven-plugin</artifactId>
    <version>2.7</version>
    <configuration>
        <rulesUri>http://www.mycompany.com/maven-version-rules.xml</rulesUri>
    </configuration>
</plugin>

最も注目に値する、ローカルファイルを参照することもできます。

<rulesUri>file:///home/andrea/maven-version-rules.xml</rulesUri>

6.1. バージョンをグローバルに無視する

特定の正規表現に一致するバージョンを無視するようにルールファイルを構成できます：

<ruleset comparisonMethod="maven"
  xmlns="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0 
  http://mojo.codehaus.org/versions-maven-plugin/xsd/rule-2.0.0.xsd">
    <ignoreVersions>
        <ignoreVersion type="regex">.*-beta</ignoreVersion>
    </ignoreVersions>
</ruleset>

6.2. ルールごとのバージョンを無視する

最後に、ニーズがより具体的である場合は、代わりに一連のルールを作成できます。

<ruleset comparisonMethod="maven"
  xmlns="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0 
    http://mojo.codehaus.org/versions-maven-plugin/xsd/rule-2.0.0.xsd">
    <rules>
        <rule groupId="com.mycompany.maven" comparisonMethod="maven">
            <ignoreVersions>
                <ignoreVersion type="regex">.*-RELEASE</ignoreVersion>
                <ignoreVersion>2.1.0</ignoreVersion>
            </ignoreVersions>
        </rule>
    </rules>
</ruleset>

7. 結論

安全で、自動的に、Maven3に準拠した方法で、プロジェクトの依存関係を確認および更新する方法を見てきました。

いつものように、ソースコードはGitHub で利用可能であり、スクリプトとともに、すべてを段階的に、複雑にすることなく紹介するのに役立ちます。

実際の動作を確認するには、プロジェクトをダウンロードしてターミナルで実行します（Windowsを使用している場合はGit Bashで実行します）。

./run-the-demo.sh

getdocs

13036