さまざまな依存関係を持つ Maven マルチモジュール プロジェクトのセットアップ
-
24-12-2019 - |
質問
最初にこれだけ言っておきます。私は Maven を初めて使用します。つまり、調べてみましたが、次の質問に対する答えが見つかりませんでした。同様の質問に対する回答は見つかりましたが、このシナリオではありませんでした。あるいは、私が単に答えを誤解していて、これはマルチモジュールのセットアップで簡単に解決できるかもしれません。
次の依存関係階層があるとします。
database
| |
| +---core
| | |
| | +---business
| | |
| | +------App1
| | |
| | +------App2
| |
| +---------------App3
|
+----------------------App4
変更により「アップストリーム」モジュール/アプリの新しいリリースのみが発生するように機能させたいと考えています。これは確かにマルチモジュール Maven セットアップの単純なケースですか、それとも何か他のことをする必要がありますか?
解決
1 つのコンポーネントをリリースすることで各プロジェクトの新しいリリースが生成されるようにしたい場合は、単に次を使用します。 maven-リリース-プラグイン: http://maven.apache.org/maven-release/maven-release-plugin/.
ドキュメンテーション
ドキュメントに従って、これは次のようになります:
- ソースにコミットされていない変更がないことを確認する
- スナップショットの依存関係がないことを確認する
- POM のバージョンを x-SNAPSHOT から新しいバージョンに変更します (使用するバージョンの入力を求められます)。
- POM 内の SCM 情報を変換して、タグの最終宛先を含めます。
- 変更した POM に対してプロジェクト テストを実行して、すべてが正常に動作していることを確認します。
- 変更された POM をコミットする
- SCM 内のコードにバージョン名をタグ付けします (これは要求されます)。
- POM 内のバージョンを新しい値 y-SNAPSHOT にバンプします (これらの値も要求されます)
- 変更された POM をコミットする
Maven のマルチ モジュール構造により、それらは相互にリンクされ、各プロジェクトは新しいリリースに追加されます。
一言で言えば、これは次のようになります:
- バージョン 1.0-SNAPSHOT を移動 --> 1.1-SNAPSHOT
- タグ1.0
- 1.0.jar を生成します (戦争でも何でも)
プラグインの使用法
SCM が正しく定義され、リポジトリと配布管理が構成されていると仮定すると、次の行を追加するだけです。
<project>
[...]
<build>
[...]
<plugins>
[...]
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.4.2</version>
<!-- optional, basic format is ${project.artifactId}-${project.version}.${project.type}-->
<configuration>
<tagNameFormat>v@{project.version}</tagNameFormat>
</configuration>
</plugin>
[...]
</plugins>
[...]
</build>
[...]
</project>
そして電話してください
mvn release:prepare
mvn release:perform
継承と依存関係
次の 2 つの異なる Maven アプローチを検討してください。
- 継承、つまり親モジュールとマルチ/サブモジュールを意味します
- 集約、言い換えれば:依存関係の使用
マルチ Maven プロジェクトでは、親を含むすべてのモジュールが同じライフサイクルを共有します。1 つを解放することはすべてを解放することを意味するため、1 つだけを解放することはナンセンスです。
あなたの場合、アプリ 4 に影響を与えずにアプリ 1 から 3 を変更することはできません。アプリ 4 がアプリ 1 に依存する場合、明らかにアプリ 1 はアプリ 4 に依存できません (循環参照は許可されません)。
したがって、App4 と App1 を 3 つのライフサイクルに分離したい場合は、マルチモジュールを使用するのではなく、親プロジェクト、または企業 > メイン プロジェクト > サブプロジェクト (サブモジュールではない) のような pom の階層を共有する必要があります。その後、App 4 と App 1 の間の依存関係を宣言するだけです。(...app4 pom.xml に)
もう一つの考え:プロジェクトとサブモジュールの名前が奇妙に聞こえます。「古典的な」階層は、多くの場合、次のようになります (大規模プロジェクトの複数のビジネス オブジェクト ドメインを考慮した場合)。
Main Project (sometimes EAR) --> POM
|-- Business Object / DAO --> POM
| |-- Domain 1 --> JAR
| `-- Domain 2 --> JAR
|-- Core (depends on BO) --> JAR
`-- IHM / Web App (depends on core) --> WAR
したがって、データベースが階層の最上位になることはほとんどありません。