最新バージョンの依存関係を使用するように Maven に指示するにはどうすればよいですか?
-
09-06-2019 - |
質問
Maven では、依存関係は通常次のように設定されます。
<dependency>
<groupId>wonderful-inc</groupId>
<artifactId>dream-library</artifactId>
<version>1.2.3</version>
</dependency>
さて、頻繁にリリースされるライブラリを使用している場合、<version> タグを常に更新するのは少々煩わしい場合があります。Maven に常に (リポジトリからの) 利用可能な最新バージョンを使用するように指示する方法はありますか?
解決
注記:
この回答は Maven 2 にのみ適用されます。言及された LATEST
そして RELEASE
メタバージョン 「再現可能なビルドのために」Maven 3 では削除されました, 6年以上前。こちらを参照してください Maven 3 準拠のソリューション.
常に最新バージョンを使用したい場合、Maven にはバージョン範囲の代わりに使用できる 2 つのキーワードがあります。使用しているプラグイン/依存関係を制御できないため、これらのオプションは注意して使用する必要があります。
プラグインまたは依存関係に依存する場合、バージョン値として LATEST または RELEASE を使用できます。LATEST は、特定のアーティファクトの最新のリリースまたはスナップショット バージョン、つまり特定のリポジトリに最後にデプロイされたアーティファクトを指します。RELEASE は、リポジトリ内の最後の非スナップショット リリースを指します。一般に、成果物の非特定のバージョンに依存するソフトウェアを設計することはベスト プラクティスではありません。ソフトウェアを開発している場合は、サードパーティ ライブラリの新しいリリースがリリースされたときにバージョン番号を更新する必要がないように、便宜上 RELEASE または LATEST を使用するとよいでしょう。ソフトウェアをリリースするときは、自分の管理下にないソフトウェア リリースによってビルドやプロジェクトが影響を受ける可能性を減らすために、プロジェクトが特定のバージョンに依存していることを常に確認する必要があります。LATEST と RELEASE を使用する場合は、慎重に使用してください。
を参照してください。 Maven ブックの POM 構文セクション 詳細については。または、このドキュメントを参照してください 依存関係のバージョン範囲, 、 どこ:
- 角括弧 (
[
&]
) は「閉じた」(両端を含む) を意味します。 - 括弧 (
(
&)
) は「オープン」(排他的) を意味します。
以下に、さまざまなオプションを示す例を示します。Maven リポジトリでは、com.foo:my-foo に次のメタデータがあります。
<?xml version="1.0" encoding="UTF-8"?><metadata>
<groupId>com.foo</groupId>
<artifactId>my-foo</artifactId>
<version>2.0.0</version>
<versioning>
<release>1.1.1</release>
<versions>
<version>1.0</version>
<version>1.0.1</version>
<version>1.1</version>
<version>1.1.1</version>
<version>2.0.0</version>
</versions>
<lastUpdated>20090722140000</lastUpdated>
</versioning>
</metadata>
そのアーティファクトへの依存関係が必要な場合は、次のオプションがあります (その他 バージョン範囲 もちろん指定することもできますが、ここでは関連するものだけを示します)。
正確なバージョンを宣言します (常に 1.0.1 に解決されます)。
<version>[1.0.1]</version>
明示的なバージョンを宣言します (衝突が発生しない限り、Maven が一致するバージョンを選択する場合は常に 1.0.1 に解決されます)。
<version>1.0.1</version>
すべての 1.x のバージョン範囲を宣言します (現在は 1.1.1 に解決されます)。
<version>[1.0.0,2.0.0)</version>
無制限のバージョン範囲を宣言します (2.0.0 に解決されます)。
<version>[1.0.0,)</version>
バージョンを LATEST として宣言します (2.0.0 に解決されます) (Maven 3.x から削除されました)
<version>LATEST</version>
バージョンを RELEASE として宣言します (1.1.1 に解決されます) (Maven 3.x から削除されました)。
<version>RELEASE</version>
デフォルトでは、独自のデプロイメントは Maven メタデータの「最新」エントリを更新しますが、「リリース」エントリを更新するには、 Maven スーパー POM. 。これは、「-Preelease-profile」または「-DperformRelease=true」のいずれかを使用して行うことができます。
Maven が依存関係のバージョン (LATEST、RELEASE、バージョン範囲) を選択できるようにするアプローチでは、後のバージョンでは動作が異なる可能性があるため (たとえば、依存関係プラグインが以前にデフォルトを切り替えていたなど)、ビルド時間の問題が発生する可能性があることを強調する価値があります。値が true から false になり、結果が混乱します)。
したがって、一般的には、リリースで正確なバージョンを定義することをお勧めします。として ティムの答え と指摘すると、 Maven-バージョン-プラグイン は、依存関係のバージョン、特に バージョン:最新バージョンを使用 そして バージョン:最新リリースを使用 目標。
他のヒント
このトピックが古いことはわかっていますが、質問とOPが提供した回答を読むと、 Maven バージョン プラグイン 実際には、彼の質問に対するより良い答えだったかも知れません。
特に次の目標が役立つ可能性があります。
- バージョン:最新バージョンを使用 POMですべてのバージョンを検索します これは新しいバージョンであり、 それらを最新の バージョン。
- バージョン:最新リリースを使用 POMでSNAPSHOT以外のすべてのPOMを検索します。 新しいバージョンは、 release で置き換え、 最新リリースバージョン。
- バージョン:更新プロパティ で定義されたプロパティを更新します。 project を 利用可能な最新バージョンの 特定の依存関係。これは、 依存関係のスイートがある場合に便利です すべてが 1 つのバージョンにロックされている必要があります。
次のような他の目標も提供されます。
- バージョン:表示依存関係の更新 プロジェクトの依存関係をスキャンし、 これらのレポートを作成します 新しい依存関係 利用可能なバージョン。
- バージョン:表示プラグインの更新 プロジェクトのプラグインをスキャンし、 これらのプラグインのレポートを生成します 新しいバージョンが利用可能です。
- バージョン:親の更新 プロジェクトの親セクションを次のように更新します。 最新のものを参照していること 利用可能なバージョン。たとえば、 企業のルートPOMを使用する場合、この 目標は、必要に応じて役立ちます 最新の 企業ルート POM のバージョン。
- バージョン:更新子モジュール の親セクションを更新します。 プロジェクトの子モジュールなので、 version は、 現在のプロジェクト。たとえば、 また、アグリゲーター POM が プロジェクトの親 aggregates と子と 親バージョンが同期しなくなると、 Mojoは、 子モジュール。(注:次のことが必要な場合があります Maven を -N オプションで呼び出します。 この目標を実行するために、 プロジェクトがひどく壊れているので、 バージョンが原因でビルドできません ミスマッチ)。
- バージョン:ロック スナップショット pom ですべての -SNAPSHOT を検索します。 バージョンを作成し、それらを その現在のタイムスタンプバージョン -SNAPSHOT (例:-20090327.172306-4
- バージョン:スナップショットのロック解除 POMですべてのタイムスタンプを検索します ロックされたスナップショットのバージョンと置換 -SNAPSHOTで指定します。
- バージョン:解決範囲 バージョン範囲を使用して依存関係を検索し、 範囲を特定の バージョンが使用されています。
- バージョン:使用リリース pom ですべての -SNAPSHOT バージョンを検索します。 リリースされ、 対応するリリースでそれら バージョン。
- バージョン:次のリリースを使用 POMでSNAPSHOT以外のすべてのPOMを検索します。 新しいバージョンは、 release で置き換え、 次のリリースバージョン。
- バージョン:次のバージョンを使用 POMですべてのバージョンを検索します これは新しいバージョンであり、 を次のバージョンに置き換えます。
- バージョン:コミット pom.xml.versionsBackup ファイルを削除します。フォーム 内蔵の「Poor Man's」の半分 SCM」です。
- バージョン:元に戻す pom.xml ファイルを pom.xml.versionsバックアップファイル。フォーム 内蔵の「Poor Man's」の半分 SCM」です。
今後の参考のために含めておこうと思いました。
ぜひご覧ください このページ (セクション「依存関係のバージョン範囲」)。あなたがやりたいことは次のようなものです
<version>[1.2.3,)</version>
これらのバージョン範囲は Maven2 に実装されています。
他の人とは異なり、あなたがそうする理由はたくさんあると思います 常に最新のものを求める バージョン。特に、継続的なデプロイメントを行っており (1 日に 5 つほどリリースすることもあります)、複数モジュールのプロジェクトを実行したくない場合は特にそうです。
私がやっているのは、Hudson/Jenkins にビルドごとに次のことを実行させることです。
mvn clean versions:use-latest-versions scm:checkin deploy -Dmessage="update versions" -DperformRelease=true
つまり、version プラグインと scm プラグインを使用して依存関係を更新し、ソース管理にチェックインします。はい、CI に SCM チェックインを実行させます (Maven リリース プラグインの場合はいずれにせよ実行する必要があります)。
必要なものだけを更新するようにバージョン プラグインをセットアップするとよいでしょう。
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>1.2</version>
<configuration>
<includesList>com.snaphop</includesList>
<generateBackupPoms>false</generateBackupPoms>
<allowSnapshots>true</allowSnapshots>
</configuration>
</plugin>
リリース プラグインを使用して、-SNAPSHOT を処理するリリースを実行し、-SNAPSHOT のリリース バージョンがあることを検証します (これは重要です)。
私と同じことを行うと、すべてのスナップショット ビルドの最新バージョンと、リリース ビルドの最新リリース バージョンが取得されます。ビルドも再現可能になります。
アップデート
このワークフローの詳細を尋ねるコメントがいくつかあることに気付きました。私たちはもうこの方法を使用していません。その主な理由は、Maven バージョンのプラグインにバグがあり、一般的に本質的に欠陥があるからです。
これには欠陥があります。バージョンを調整するためにバージョンプラグインを実行するには、pom が正しく動作するために既存のすべてのバージョンが存在する必要があるからです。つまり、pom で参照されているバージョンが見つからない場合、プラグインは最新バージョンに更新できないということです。ディスクスペースの理由から古いバージョンをクリーンアップすることが多いため、これは実際にはかなり面倒です。
実際には、バージョンを調整するには Maven とは別のツールが必要です (そのため、正しく実行するために pom ファイルに依存する必要はありません)。私はそのようなツールを Bash という低級言語で作成しました。スクリプトは、バージョン プラグインと同様にバージョンを更新し、pom をソース管理にチェックインします。また、mvn バージョンのプラグインよりも 100 倍ほど高速に実行されます。残念ながら、これは一般公開向けに書かれていませんが、興味がある人は、そのようにして gist または github に置くこともできます。
ワークフローに戻ります。いくつかのコメントで、これが私たちが行うことについて尋ねられました。
- 独自のリポジトリに 20 ほどのプロジェクトがあり、独自の jenkins ジョブが含まれています
- リリース時にはMavenリリースプラグインが使用されます。そのワークフローについては、プラグインのドキュメントで説明されています。Maven リリース プラグインはひどいものですが (親切にしています)、機能します。いつかこの方法をより最適なものに置き換える予定です。
- プロジェクトの 1 つがリリースされると、jenkins は特別なジョブを実行し、すべてのバージョンの更新ジョブを呼び出します (maven jenkins リリース プラグインも非常にひどいため、jenkins がリリースを認識する方法は複雑です)。
- すべてのバージョンの更新ジョブは、20 個のプロジェクトすべてについて認識しています。これは実際には、モジュール セクション内のすべてのプロジェクトを依存関係の順序で特定するアグリゲーター ポンポンです。Jenkins は、すべてのプロジェクトをプルしてバージョンを最新に更新し、poms をチェックインする魔法の groovy/bash foo を実行します (これもモジュール セクションに基づいた依存関係の順序で行われます)。
- 各プロジェクトで、pom が変更された場合 (依存関係のバージョン変更により) チェックインされ、すぐに jenkins に ping を送信して、そのプロジェクトに対応するジョブを実行します (これは、ビルド依存関係の順序を維持するためです。それ以外の場合は、自由に操作できます) SCM ポーリング スケジューラの)。
現時点では、とにかくリリースと自動バージョンを一般的なビルドとは別のツールにするのは良いことだと私は考えています。
上記の問題のせいで Maven は最悪だと思うかもしれませんが、解析しやすい宣言型を持たないビルド ツールではこれは実際にはかなり困難です。 拡張可能な 構文 (別名 XML)。
実際、bash/groovy スクリプトにヒントを与えるために、名前空間を通じてカスタム XML 属性を追加しています (例:このバージョンは更新しないでください)。
依存関係の構文は次の場所にあります。 依存関係のバージョン要件の仕様 ドキュメンテーション。完全を期すため、以下に示します。
依存関係」
version
要素は、有効な依存関係バージョンを計算するために使用されるバージョン要件を定義します。バージョン要件の構文は次のとおりです。
1.0
:1.0 の「ソフト」要件 (依存関係の他のすべての範囲に一致する場合の単なる推奨事項)[1.0]
:1.0 の「ハード」要件(,1.0]
:x <= 1.0[1.2,1.3]
:1.2 <= x <= 1.3[1.0,2.0)
:1.0 <= x < 2.0[1.5,)
:x >= 1.5(,1.0],[1.2,)
:x <= 1.0 または x >= 1.2;複数のセットはカンマで区切ります(,1.1),(1.1,)
:これは 1.1 を除外します (たとえば、 このライブラリと組み合わせて作業する)
あなたの場合、次のようなことができます <version>[1.2.3,)</version>
開発中に明らかに大きく変更される開発バージョンに依存している可能性はありますか?
開発リリースのバージョンを増やす代わりに、必要に応じて上書きするスナップショット バージョンを使用することもできます。これは、マイナーな変更のたびにバージョン タグを変更する必要がないことを意味します。1.0-スナップショットのようなもの...
しかし、もしかしたらあなたは何か他のことを達成しようとしているかもしれません ;)
LATEST を使用している人は、必ず -U を指定してください。そうしないと、最新のスナップショットが取得されません。
mvn -U dependency:copy -Dartifact=com.foo:my-foo:LATEST
// pull the latest snapshot for my-foo from all repositories
この質問が提起された時点では、Maven のバージョン範囲にいくつかの問題がありましたが、これらは Maven の新しいバージョンでは解決されています。この記事では、バージョン範囲の仕組みと、Maven がバージョンをどのように理解するかをよりよく理解するためのベスト プラクティスについて詳しく説明しています。 https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN8855
真実は、3.x であってもまだ機能し、驚くべきことにプロジェクトはビルドしてデプロイされます。しかし、LATEST/RELEASE キーワードは m2e や Eclipse で問題を引き起こし、LATEST/RELEASE を通じてデプロイされた依存関係に依存するプロジェクトもバージョンを認識できません。
また、バージョンをプロパティとして定義し、それを他の場所で参照しようとすると、問題が発生します。
したがって、結論としては、 バージョン-maven-プラグイン できれば。
場合によっては、バージョン範囲を使用したくない場合があります。これは、特に継続的デリバリーが行われており、主に大量の開発が行われている場合に、依存関係の解決が「遅い」と思われるためです。
回避策の 1 つは、 バージョン-maven-プラグイン. 。たとえば、次のようにプロパティを宣言できます。
<properties>
<myname.version>1.1.1</myname.version>
</properties>
そして、versions-maven-plugin を pom ファイルに追加します。
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>2.3</version>
<configuration>
<properties>
<property>
<name>myname.version</name>
<dependencies>
<dependency>
<groupId>group-id</groupId>
<artifactId>artifact-id</artifactId>
<version>latest</version>
</dependency>
</dependencies>
</property>
</properties>
</configuration>
</plugin>
</plugins>
</build>
次に、依存関係を更新するには、次の目標を実行する必要があります。
mvn versions:update-properties validate
1.1.1 より新しいバージョンがある場合は、次のメッセージが表示されます。
[INFO] Updated ${myname.version} from 1.1.1 to 1.3.2
Maven が依存関係の最新バージョンを使用する必要がある場合は、次のように使用できます。 バージョン Maven プラグイン このプラグインの使用方法については、Tim がすでに良い答えを示しています。彼の答えに従ってください。 答え.
しかし、開発者として、私はこの種の実践はお勧めしません。なぜ?
その理由に対する答えはすでに与えられています パスカル・ティベント 質問のコメントで
私はこの方法(またはバージョン範囲の使用)を本当にお勧めしません ビルドの再現性のために。突然始まるビルド 不明な理由で失敗するのは、手動で更新するよりもはるかに厄介です バージョン番号。
私はこのタイプの練習をお勧めします。
<properties>
<spring.version>3.1.2.RELEASE</spring.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${spring.version}</version>
</dependency>
</dependencies>
保守もデバッグも簡単です。POM はすぐに更新できます。
Maven 3.5.4の私のソリューション、EclipseでNexusを使用:
<dependency>
<groupId>yilin.sheng</groupId>
<artifactId>webspherecore</artifactId>
<version>LATEST</version>
</dependency>
次に日食で: atl + F5
, を選択し、 force update of snapshots/release
わたしにはできる。