大きなプロジェクトを分割してマルチモジュールのMavenプロジェクトを作成する
依存関係管理にMavenを使用しているSpring-MVCアプリケーションに取り組んでいます。プロジェクトが大きいため、プロジェクトをいくつかの部分に分割することを考えています。私はいくつかの疑問を持っていました。
現在、サーバー上のApache Tomcatに単一のWARファイルをROOT.warとしてデプロイしています。プロジェクトが大きいため、通知と電子メール、サードパーティサービス、プッシュ（Cometd）、REST APIなどのWebアプリケーションの部分があります。現在、それらのすべてがクラブ化されており、相互に依存しています。たとえば、通知はユーザー向けに調整されているため、NotificationオブジェクトもPersonオブジェクトに依存します。
大きなプロジェクトを分割する主な目的は、バグの修正、機能の追加、テストなどのために、個々のモジュールで作業できるようにすることです。また、満足すると、アプリケーション全体ではなく、サーバー上でこのモジュールのみを置き換えることができます。 これは可能ですか？
前述のとおり、オブジェクト間には依存関係とマッピングがあります。異なるサブモジュール全体でそれらをどのように管理するかまたは、他のプロジェクトを含めるようにインポートステートメントだけを変更するのか？
私が言ったように、その意図は、個々のモジュールで動作し、それらをデプロイできるようにすることです（できればホット）。現在、ROOT.warのWARファイルは1つだけです。分割すると、複数のwarファイルが作成されますRLによってdomain-name.com/module_name/some_mappingとして参照されます
現在ドキュメントを確認していますが、これは、Mavenが提供するマルチモジュールで達成したい主要な目的であり、これが可能かどうかを知りたいと思っています。他に必要な情報がある場合は、お知らせください。
現在、私は春の親POMを次のように使用しています：
<parent>
<groupId>io.spring.platform</groupId>
<artifactId>platform-bom</artifactId>
<version>1.1.3.RELEASE</version>
<relativePath />
</parent>
それは可能ですか？
はい、確かに。過去の構造には、このようなプロジェクトがいくつかあります。ここで、あなたが始められることを願っています。
Mavenには、物を一緒に織り込むために使用する2つの主な機能があります。
分割統治
プロジェクトを複数の独立したプロジェクトに分割する必要があります。ここで独立とは、プロジェクト外部のコードへの参照はすべて、Mavenの依存関係を介して行われ、ソースツリーを直接マージしないことを意味します。
ソースツリーの状態によっては、これは多くの作業を表す可能性があります。それはあなたがMavenにシューホーンするためではなく、コードベースを構造化してサニタイズするための手段としてそれをしていると言いました。それをあなたの道具箱と考えてください、ここで物事を見つけるのがはるかに簡単です：
ここより：
Mavenは convention に大きく依存しています。そのため、Mavenがよりよく整理されていれば、Mavenがさらに役立ちます。とは言っても、独自の規則に合わせて再編成する必要がある場合があります。ここでアドバイスを1つ挙げる必要がある場合、Mavenの規則に合わせて内容を変更する方が、Mavenを試して構成するよりもはるかに簡単です。あなたの慣習を理解してください。
これらのプロジェクトがメインアプリケーション以外でも使用できる場合、それらは真に独立したライブラリとして機能し、Mavenの依存関係を含むことができます。それらは（アプリケーションソースツリーではなく）独自のリポジトリに存在し、メインアプリケーションのどの部分にも依存しないようにする必要があります。
アプリケーションのコア部分は、プロジェクトに分割されると、モジュールとしてまとめることができます。通常は、アプリのメインソースフォルダーのサブフォルダーとして配置します。
また、アプリの親POMにはモジュール宣言が含まれます。また、アプリのすべての一般的な依存関係を配置し、ビルドプラグインとその構成のほとんどを宣言します。ここでも、モジュールで再利用できるアプリケーションのバージョンなどのプロパティのグループを配置することを強くお勧めします。すべてが同じバージョンであり、バージョンが1か所にあると、管理がはるかに簡単になり、これでうまくいきます。
ツーリング
1より大きいチームの場合は、Mavenの依存関係のリポジトリをインストールすることを強くお勧めします。 Artifactory 、 Nexus または Archiva を見てください。これらに直接インストールするようにPOMファイルを構成することができるので、一度実行するとオーバーヘッドはそれほど大きくなりませんが、適切な場所に適切なjarを使用して依存関係を解決する時間を大幅に節約できます。
次の論理的なステップをツール化することに関しては、ここで継続的インテグレーションシステム（ Jenkins 、もっとたくさんあります）です。これは、テストを実行するソースの構築とアーティファクトへのプッシュを処理します。これをすべて行うと、コードを操作するだけで、残りは正しく機能します。
アプリをwarとしてパッケージ化しているため mavenはwarの構築を処理できます であり、jarファイルやその他の同様の作業をマージする必要がないため、すべての依存関係を適切な場所に配置するため、心配する必要はありません。
例
ここでもっと長く続けることができましたが、良い例に勝るものはありません。同様の規模のプロジェクトについてgithubを調べ、pomファイルとフォルダー階層をどのように構築したかを確認してください。複数を見てください、いくつかは他のものよりあなたのセットアップにうまく適合します、実際にはどれも具体化しませんthe真実ですが、それを行う方法についてのあなたの考えを刺激するのに十分なはずです。
Jenkins を例にとります：
親POM が非常に広範であることがわかります。
このセクションでわかるように、モジュールを使用します。
<modules>
<module>core</module>
<module>war</module>
<module>test</module>
<module>cli</module>
</modules>
また、各モジュールは、POMも含む同じ名前のサブフォルダーに対応しています。これを好きなだけ入れ子にすることができますが、正気度の範囲内に収めることができます;）。
小さなスタート
Mavenを使用したことがない場合は、すぐにモジュールから開始しないことをお勧めします。それをゆっくりと始めて、あなたが持っているかもしれないより単純なライブラリの1つから始めて、それをmavenプロジェクトにします。次に、メインアプリケーションを単純なMavenプロジェクトにします。それが機能したら、単純な依存関係の追加を開始してから、最初のモジュールを分割します。
Mavenは優れたツールですが、特に物事がうまくいかない場合は、首の痛みにもなることがあります。あなたの最初の移動の全体の奇妙なところから始めて、災害のためのレシピです（私のためでした！）。
少し奇妙なことがあれば、いつでもmvn help:effective-pomコマンドを使用して、Mavenが実際に理解したことを確認します。
プラグイン
あなたのコメントから私はあなたが達成したいことをよりよく理解しています。この場合は、プラグインアプローチを使用します。作業を分離する拡張ポイントのAPIを公開するプロジェクトを作成します。次に、これを実装する新しいプロジェクトの依存関係として使用できます。メインアプリケーションでは、これらの実装に適切な依存関係を追加するだけで（今回はMavenモジュールを使用しません）、問題ありません。最終的に、メインアプリケーションプロジェクトには、外部プロジェクトで実行され、依存関係を通じて読み込まれるすべてのソースコードがほとんどありません。
ただし、コアが変更されたかどうかに関係なく、この方法ではアプリケーション全体を再デプロイする必要があります。戦争は依存関係から静的に構築されるため、コアの1つを変更すると全体が再構築されます。それは実際よりも最悪に聞こえます。事実上、新しい変更のみが実際にビルドされ、残りは基本的に以前のjarのコピーになります。ただし、すべてがwarファイルに含まれているため、サーバーを再構築し、サーバーを停止して再起動する必要があります。
さらに進む必要がある場合、不可能ではありませんが、少し複雑になります。 OSGIを調べることをお勧めします Apache Felix 他の実装もありますが、始めることができます。これにより、外部jarを取得して適切なプラグインにすることができます。動的な再読み込みと更新への扉を開くコンポーネントのランタイムライフサイクルをより詳細に制御できます。ただし、コアを大幅に変更する必要があるため、おそらく最初の出発点にはなりません。ただし、プロジェクトが適切に分離されていて、すべての部分が希望どおりに分離されている場合、更新時にアプリケーションの開始と停止が大きな問題となる場合は、次のステップとして自然に行うことができます。
モジュールと依存関係の基本的な違いは次のとおりです。
- モジュールは、理想的にはサブフォルダーとして、メインアプリケーションと同じソースツリーに存在します。
- 依存関係はどこにあってもかまいません。
あなたは聖書を見つけることができます ここ 。
これがお役に立てば幸いです。