さまざまな依存関係を持つ Maven マルチモジュール プロジェクトのセットアップ

Question

最初にこれだけ言っておきます。私は Maven を初めて使用します。つまり、調べてみましたが、次の質問に対する答えが見つかりませんでした。同様の質問に対する回答は見つかりましたが、このシナリオではありませんでした。あるいは、私が単に答えを誤解していて、これはマルチモジュールのセットアップで簡単に解決できるかもしれません。

次の依存関係階層があるとします。

database
|  |
|  +---core
|      |  |
|      |  +---business 
|      |        |
|      |        +------App1
|      |        |
|      |        +------App2
|      |
|      +---------------App3
|
+----------------------App4

変更により「アップストリーム」モジュール/アプリの新しいリリースのみが発生するように機能させたいと考えています。これは確かにマルチモジュール Maven セットアップの単純なケースですか、それとも何か他のことをする必要がありますか?

Answer 1

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

したがって、データベースが階層の最上位になることはほとんどありません。