7 Mavenのバージョン番号の理解

Maven環境では、バージョン番号の使用を理解することが非常に重要です。よく考えられた計画では、依存性管理ワークロードが大幅に簡素化されます。この章では、Mavenで一般的にバージョン番号がどのように機能するかに関する重要な概念について説明し、Oracle提供のアーティファクトにおけるバージョン番号の使用方法の具体的な詳細、およびOracleアーティファクトを参照する場合のバージョン番号の使用方法についても説明します。

この章の内容は次のとおりです。

7.1項「バージョン番号がMavenで機能する仕組み」
7.2項「SNAPSHOT修飾子」
7.3項「バージョン範囲参照」
7.4項「Oracle提供のアーティファクトでのMavenバージョン番号の理解」

7.1 バージョン番号がMavenで機能する仕組み

Mavenのバージョニング・スキームでは、次の標準を使用します。

MajorVersion
MinorVersion
IncrementalVersion
BuildNumber
Qualifier

次に例を示します。

MajorVersion: 1.2.1
MinorVersion: 2.0
IncrementalVersion: 1.2-SNAPSHOT
BuildNumber: 1.4.2-12
Qualifier: 1.2-beta-2

修飾子があるすべてのバージョンは、修飾子がない同じバージョン(リリース・バージョン)よりも古くなります。

次に例を示します。

1.2-beta-2は1.2よりも古いことになります。

修飾子フィールドが異なる同一バージョンは、基本的な文字列比較を使用して比較されます。

次に例を示します。

1.2-beta-2は1.2-alpha-6よりも新しくなります。

プロジェクト・バージョニング・スキームでMavenバージョニング標準に従わない場合、バージョン比較の際、Mavenではバージョン全体が単純な文字列として解釈されます。Mavenおよびその主要プラグインでは、様々なタスク(最も重要なのはリリース・プロセス)でバージョン比較が使用されます。

非標準のバージョニング・スキームを使用する場合、Mavenのリリースおよびバージョンのプラグイン・ゴールで、想定された結果がもたらされない場合があります。非標準バージョンでは基本的な文字列比較が実行されるため、バージョン比較でバージョンの順序が正しく計算されない場合があります。

たとえば、Mavenではバージョン・リストを次のように配置します。

1.0.1.0
1.0.10.1
1.0.10.2
1.0.9.3

バージョン1.0.9.3は、1.0.10.1および1.0.10.2の前に配置される必要がありますが、予期しない4番目のフィールド(.3)によってMavenではバージョンが文字列として評価されています。

Mavenでのこの影響の例は、Mavenバージョン・プラグインで見つかります。Mavenバージョン・プラグインでは、プロジェクト依存性の現在性を様々な方法でチェックするゴールが提供されます。有用なゴールの1つにversions:dependency-updates-reportがあります。versions:dependency-updates-reportゴールでは、プロジェクトの依存性階層を調査し、より新しいリリースを使用できるのはどのプロジェクトであるかをレポートします。大規模なリリースを調整する場合、このゴールは、依存性構成内の失効した参照を見つけるのに役立ちます。Mavenで新しいリリースが正しく特定されなかった場合、プラグインでも正しくレポートされません。前述の例の順序では、現在の参照が1.0.10.2であった場合、プラグインでは1.0.9.3が新しいリリースとしてレポートされます。

依存性参照でバージョン範囲を使用する予定である場合は、バージョンの解決も非常に重要になります。バージョン変更の詳細は、7.3項を参照してください。

7.2 SNAPSHOT修飾子

Mavenでは、SNAPSHOT修飾子の処理が他の修飾子とは異なります。バージョン番号の後に-SNAPSHOTが続く場合、Mavenでは、関連するMajorVersion、MinorVersionまたはIncrementalVersionの「まだリリースされていない」バージョンとみなされます。

継続的インテグレーション環境では、SNAPSHOTバージョンは、各統合ステップで必要となる再ビルドの量を最小限に抑えながら、統合ビルドを最新の状態に保つという重要な役割を果たします。

SNAPSHOTバージョン参照により、Mavenでは、依存プロジェクト・ビルド時間で最後にデプロイされたSNAPSHOT依存性インスタンスをフェッチできるようになります。SNAPSHOTは常に変わることに注意してください。エージェントがアーティファクトをデプロイするたびに、共有リポジトリで更新されます。SNAPSHOT依存性は、開発者のマシンで再フェッチされるか、またはすべてのビルドで更新されます。これにより、プロジェクト依存性参照構成に対する変更を加えることなく、依存性が最新の変更内容で更新および統合されます。

通常、アーティファクトの特定のバージョンのうち、最後にデプロイされたSNAPSHOTのみがアーティファクト・リポジトリに保持されます。特定のアーティファクトの複数の最新デプロイメントを使用してローリング・アーカイブを保持するようにリポジトリを設定できますが、通常、古いインスタンスはトラブルシューティング目的でのみ使用され、統合で使用されることはありません。

Mavenプロジェクトに基づいてジョブを定義および実行する機能を持つ継続的ビルド・サーバー(Hudsonなど)は、SNAPSHOTアーティファクトが更新された場合に認識し、更新されたアーティファクトに依存するプロジェクトを再ビルドするように設定できます。

たとえば、Mavenプロジェクト・オブジェクト・モデルにマップするHudsonビルド構成にはSNAPSHOT依存性があります。Hudsonでは、SNAPSHOT更新に関してアーティファクト・リポジトリが定期的にチェックされます。プロジェクトの依存性の更新が検出されると、プロジェクトの新しいビルドがトリガーされ、依存性の最新バージョンを使用して統合が行われます。このプロジェクトに対する依存性が他のプロジェクトにある場合、それらのプロジェクトも更新された依存性で再ビルドされます。

7.3 バージョン範囲参照

Mavenを使用すると、依存性として許容できるバージョンの範囲を指定できます。表7-1に、バージョン範囲の仕様を示します。

表7-1 バージョン範囲参照

範囲	意味
(,1.0]	x <= 1.0
1.0	1.0が使用できない場合、通常は1.0以降のバージョンを意味します。様々なMavenプラグインではこの相違の解釈が異なる場合があるため、より具体的な他のオプションを使用する方が安全です。
[1.0]	厳密に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がライブラリとの組合せで機能しないことが判明している場合、1.1は除外されます。

Mavenでは、バージョン参照で複数の一致が見つかった場合、最も高い一致バージョンが使用されます。一般に、Mavenが必要に応じて新しいバージョンの依存性を自由に選択できるが、特定のバージョンの使用が必要なときはそれを認識できるようするために、バージョン参照は必要最低限に留める必要があります。これにより、異なるバージョンの依存性が推移的依存性グラフの複数箇所で指定された場合に、最適なバージョンがMavenで選択されます。このような競合が発生する場合、Mavenではすべての参照から最上位のバージョンが選択されます。

バージョン範囲を使用する選択肢があるため、SNAPSHOTバージョンを使用する有用性に疑問を持つかもしれません。バージョン範囲式を使用してある程度同じ結果を得ることもできますが、次の理由から、SNAPSHOTは継続的ビルド・システムでより適切に機能します。

Mavenアーティファクト・リポジトリ・マネージャでは、SNAPSHOTが次期バージョン範囲よりも効率的に処理されます。単一のアーティファクトを1日に複数回デプロイできるため、リポジトリで保持される固有のインスタンスの数は急速に増える可能性があります。
非SNAPSHOTリリース・バージョンは無期限に保持されます。新しいバージョンを継続的にリリースし、ビルド番号やバージョンが増加していくと、記憶域要件はすぐに管理不能になります。リポジトリ・マネージャは、新しいインスタンス用の領域を確保するために古いSNAPSHOTを破棄するように設計されているため、必要となる記憶域容量は一定になります。
SNAPSHOTは、MavenおよびMavenのリリース・プロセスでも認識されるため、リリース・ビルドの実行時に利点がもたらされます。

7.4 Oracle提供アーティファクトのMavenバージョン番号の理解

Mavenバージョン番号がOracle提供アーティファクトで使用される場合、次の2つの重要なシナリオがあります。

アーティファクトのMaven座標、つまりアーティファクトのPOMのproject.version
他のアーティファクトを参照するPOMの依存性セクション

この項では、これら両方のシナリオでバージョン番号がOracleアーティファクトに定義される方法について説明します。

7.4.1 Maven座標のバージョン番号

POMファイルで定義されたアーティファクトのバージョン番号は、次で説明するように、リリース済製品のバージョン番号(5桁を使用して表される12.1.2.0.0など)と同じです。

x.x.x-y-zの場合:

x.x.xは、12.1.2などのリリース・バージョン番号です。
yは、0,1,2,3,…などの、先頭にゼロが付かないPatchSet番号です。
zは、0,1,2,3,…などの、先頭にゼロが付かないBundle Patch番号です。
ピリオドとハイフンはリテラルです。

注意:

(POMのproject.versionで指定した)アーティファクトのバージョン番号では、(POMのproject.dependencies.dependency.versionで指定した)依存性で使用されるバージョン番号範囲とは異なる形式が使用されます。

Oracle所有のコンポーネントのリリース・バージョン番号は、個別パッチで変更されません。リリース・バージョン番号は、リリースで変更され、コンポーネントが前のリリースで変更されていない場合でも、常にリリースと一致します。

パッチ・セット(4番目の位置)は、パッチ・セットを適用すると変更されます。バンドル・パッチ(5番目の位置)は、Bundle Patch、Patch set Updateまたは同等のパッチ(このタイプのパッチの名前は製品によって異なります)を適用した場合に変更されます。

次に、有効なバージョン番号の例を示します。

12.1.2-0-0    12.1.2-1-0   12.1.2-2-0
12.1.2-0-1    12.1.2-1-1   12.1.2-2-1
                 ...              
12.1.2-0-10   12.1.2-1-1   12.1.2-2-1

7.4.2 依存性でのバージョン番号範囲

Oracle提供のMavenアーティファクトで依存性が指定される2つの重要なシナリオは、次のとおりです。

Oracle製品の一部であるアーティファクトのPOMファイル内
独自のプロジェクトに含めたPOMファイル内

バージョン番号範囲は、両方のシナリオで指定される必要があります。この項では、バージョン番号範囲がOracle提供のアーティファクトで指定される仕組み、およびOracle提供のアーティファクトで依存性を宣言するタイミングについて説明します。

他のアーティファクトで依存性を指定する場合は、具体的で正しい構文を使用して、不正または不適切なバージョンの依存性が定義で使用されないようにする必要があります。

[x.x.x,y.y.y)の場合:

x.x.xは、12.1.2などのリリース・バージョン番号です。
y.y.yは、12.1.3などの次回のリリース・バージョン番号です。
大カッコ、ピリオド、コマンドおよび小カッコは、リテラルです。

依存性の指定方法として正しい例は、次のとおりです。

[12.1.2,12.1.3)

表7-1で示しているように、前の例では、使用可能な最新バージョンは、12.1.2以降であり、かつ12.1.3よりも小さいことを示しています。

Oracle提供のアーティファクトで使用されるバージョン番号スキームにより、バージョン番号が正しくソートされるようになり、たとえば、次のバージョンは示された順序(古いものから新しいもの)でMavenによって解決されます。

12.1.2-0-0, 12.1.2-0-1, 12.1.2-0-2, 12.1.2-0-10, 12.1.2-1-0, 12.1.2-1-1, 12.1.2-1-2, 12.1.2-1-10, 12.1.2-0-0, 12.1.3-0-0

特定のパッチ・セットやバンドル・パッチに依存する依存性を指定する必要がある場合、たとえば、新しいAPIが導入された場合は、4番目または4番目と5番目の桁をそれぞれ含める必要があります。

次に例を示します。

[12.1.2-2,12.1.3)      depends on 12.1.2 with PatchSet 2
[12.1.2-2-5,12.1.3)     depends on 12.1.2 with PatchSet 2 and Bundle Patch 5