マルチプロジェクト ビルドで親 POM を構成する方法はいくつかあるようですが、それぞれの利点と欠点について何かご意見がある方はいらっしゃいますか。
親POMを持つ最も簡単な方法は、プロジェクトのルートに配置することです。
myproject/
myproject-core/
myproject-api/
myproject-app/
pom.xml
pom.xmlは親プロジェクトであると同時に、-core -apiおよび-appモジュールを記述します。
次の方法は、親ディレクトリをサブディレクトリに分離することです。
myproject/
mypoject-parent/
pom.xml
myproject-core/
myproject-api/
myproject-app/
親 pom にはまだモジュールが含まれていますが、それらは相対的です (例: ../myproject-core)
最後に、モジュール定義と親を分離するオプションがあります。
myproject/
mypoject-parent/
pom.xml
myproject-core/
myproject-api/
myproject-app/
pom.xml
親 pom には「共有」構成 (dependencyManagement、プロパティなど) が含まれ、myproject/pom.xml にはモジュールのリストが含まれます。
大規模なビルドに拡張できるようにすることを意図しているため、多数のプロジェクトと成果物に拡張できる必要があります。
ボーナスの質問をいくつか紹介します。
- ソース管理、デプロイメント ディレクトリ、共通プラグインなどのさまざまな共有構成を定義するのに最適な場所はどこですか (親を想定していますが、これに悩まされることが多々あり、共通プロジェクトではなく各プロジェクトに配置されてしまいます)。
- Maven-release プラグイン、hudson、nexus は、マルチプロジェクトの設定方法をどのように処理しますか (おそらく大きな質問ですが、マルチプロジェクト ビルドの設定方法によって誰かが困惑したことがあるかどうかの方が重要です)。
編集: 各サブプロジェクトには独自の pom.xml がありますが、簡潔にするために省略しました。
ベストアンサー1
私の意見では、この質問に答えるには、プロジェクトのライフサイクルとバージョン管理の観点から考える必要があります。言い換えると、親 pom には独自のライフサイクルがあるか、つまり他のモジュールとは別にリリースできるかどうかということです。
答えが「はい」の場合(質問やコメントで言及されているほとんどのプロジェクトがこれに該当します)、親 pom には VCS と Maven の観点から独自のモジュールが必要になり、VCS レベルでは次のようになります。
root
|-- parent-pom
| |-- branches
| |-- tags
| `-- trunk
| `-- pom.xml
`-- projectA
|-- branches
|-- tags
`-- trunk
|-- module1
| `-- pom.xml
|-- moduleN
| `-- pom.xml
`-- pom.xml
これによりチェックアウトが少し面倒になりますが、これに対処する一般的な方法は を使用することですsvn:externals。たとえば、trunksディレクトリを追加します。
root
|-- parent-pom
| |-- branches
| |-- tags
| `-- trunk
| `-- pom.xml
|-- projectA
| |-- branches
| |-- tags
| `-- trunk
| |-- module1
| | `-- pom.xml
| |-- moduleN
| | `-- pom.xml
| `-- pom.xml
`-- trunks
外部定義は次のようになります。
parent-pom http://host/svn/parent-pom/trunk
projectA http://host/svn/projectA/trunk
をチェックアウトするtrunksと、次のローカル構造 (パターン #2) が生成されます。
root/
parent-pom/
pom.xml
projectA/
pom.xmlオプションで、ディレクトリに を追加することもできますtrunks。
root
|-- parent-pom
| |-- branches
| |-- tags
| `-- trunk
| `-- pom.xml
|-- projectA
| |-- branches
| |-- tags
| `-- trunk
| |-- module1
| | `-- pom.xml
| |-- moduleN
| | `-- pom.xml
| `-- pom.xml
`-- trunks
`-- pom.xml
これはpom.xml一種の「偽の」 pom です。リリースされることはなく、このファイルはリリースされることがないため実際のバージョンは含まれず、モジュールのリストのみが含まれています。このファイルでは、チェックアウトすると次の構造になります (パターン #3)。
root/
parent-pom/
pom.xml
projectA/
pom.xml
この「ハック」により、チェックアウト後にルートから Reactor ビルドを起動できるようになり、さらに便利になります。実際、これは大規模なビルド用に Maven プロジェクトと VCS リポジトリを設定するときに私が好む方法です。問題なく動作し、拡張性も高く、必要な柔軟性をすべて提供します。
答えが「いいえ」の場合（最初の質問に戻ります）、パターン 1（機能する可能性のある最も単純なことを実行する）で対処できると思います。
さて、ボーナスの質問について:
- ソース管理、デプロイメント ディレクトリ、共通プラグインなどのさまざまな共有構成を定義するのに最適な場所はどこですか (親を想定していますが、これに悩まされることが多々あり、共通プロジェクトではなく各プロジェクトに配置されてしまいます)。
正直に言うと、ここで一般的な答えを出さない方法がわかりません (「物事を相互化するのに意味があると思うレベルを使用する」など)。とにかく、子 pom は継承された設定を常に上書きできます。
- Maven-release プラグイン、hudson、nexus は、マルチプロジェクトの設定方法をどのように処理しますか (おそらく大きな質問ですが、マルチプロジェクト ビルドの設定方法によって誰かが困惑したことがあるかどうかの方が重要です)。
私が使用しているセットアップはうまく機能しており、特に言及することはありません。
実際のところ、maven-release-plugin がパターン #1 をどのように処理するのか疑問に思います (特に、<parent>リリース時に SNAPSHOT 依存関係を持つことができないため、セクションの場合)。これは鶏が先か卵が先かという問題のように思えますが、動作するかどうか思い出せず、テストするのが面倒でした。