1

私は現在、約 12 のサブプロジェクトからなるプロジェクトに取り組んでいます。

各サブプロジェクトには、依存関係を個別に構築する POM が含まれています。

上流のサブプロジェクトには、log4j などへの依存関係を含めるのと同じ方法で、下流のサブプロジェクトを依存関係として含めます。

    <dependency>
        <groupId>log4j</groupId>
        <artifactId>log4j</artifactId>
        <version>1.2.16</version>
    </dependency>

これらの依存関係は、ローカルの Nexus リポジトリに保持されます。

これはうまくいくようです。

しかし、今日、11 か月の開発を経て、リファクタリングを念頭に置いてこれらの多数の POM ファイルを再検討することにしました。

<parent>その後、タグとタグを発見し<module>、Maven プロジェクト戦略が「正しい」かどうか疑問に思い始めています。

最上位レベルの POM (Web WAR プロジェクト) が、上記のような一連の依存関係ではなく、モジュールをリストする親 POM に変更されるように POM をリファクタリングすると、どのような利点がありますか?

私は、十数個のサブプロジェクトのほとんどが独自のライフサイクルを取り、会社の Nexus リポジトリ内で他の会社のプロジェクトのコード ライブラリとして利用できるようになると予想しています。

たとえば、マルチモジュール アプローチを使用して、プロジェクトのサブコンポーネントの構成を分割して整理する場合はありますか? それとも、プロジェクトのコンポーネント全体を表すためにモジュールを使用しますか?

4

1 に答える 1

0

これまでの皆さんの意見に感謝します。この質問は主観的なものだと認識しています。

しばらくすると、この質問に対する「正しい」答えは、別の質問によって決まるように思えました。各サブプロジェクトは独自のライフサイクルを持っていますか?

UML クラスの集約と構成を比喩として使用できると思います。サブプロジェクト (@yorkw から用語を借りるためのリーフノード) が単独で存在できない場合、または親プロジェクトの範囲外に独自のライフサイクルを持つことができない場合 (WAR、EAR など)、IMHO と言うでしょう。この構造は、親 POM でのモジュールの使用を保証します。

それ以外の場合、プロジェクトは独自の 2 本の足で立つことができるため、このプロジェクトを親への依存関係として含めることを保証する構造になっていると思います (これもまた私見です)。

于 2013-01-17T13:29:57.067 に答える