大きなプロジェクトを分割してマルチモジュールMavenプロジェクトを作成する

私は依存関係管理にMavenを使用しているSpring-MVCアプリケーションに取り組んでいます。プロジェクトが大きいので、プロジェクトをいくつかの部分に分割することを考えています。いくつか疑問がありましたが、ここで答えが得られることを願っています。

現在、ROOT.warサーバー上のApache Tomcatのように単一のWARファイルをデプロイしています。プロジェクトが大きいので、通知とメール、サードパーティサービス、PUSH（Cometd）、REST APIなどのようなwebappの部分があります。現在、それらはすべてクラブであり、互いに依存しています。たとえば、通知はユーザーに合わせて調整されるため、Notificationオブジェクトもオブジェクトに依存しPersonます。

大きなプロジェクトを分割する主な目的は、バグ修正、機能の追加、テストなどのために個々のモジュールで作業できるようにすることです。そして、満足したら、このモジュールのみをアプリケーション全体ではなくサーバー上で置き換えることができます。これは可能ですか？

前述したように、オブジェクト間に依存関係とマッピングがあります。これらは異なるサブモジュール間でどのように管理されますか、またはインポートステートメントだけが他のプロジェクトを含むように変更されますか？

私が言ったように、意図は個々のモジュールに取り組み、それらを展開できるようにすることです（できればホット）。現在、として単一のWARファイルのみがありますROOT.war。分割により複数のwarファイルが作成され、URLで参照されます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は慣習に大きく依存しているため、スタッフが整理されていればいるほど、Mavenがあなたを助けてくれます。とはいえ、独自の慣習に合わせて再編成する必要がある場合があります。ここでアドバイスをしなければならないのは、Mavenの慣習に合わせてアイテムを変更する方が、Mavenを試して設定するよりもはるかに簡単だということですあなたの慣習を理解してください。

これらのプロジェクトがメインアプリケーションの外部で使用できる場合、それらは真に独立したライブラリとして存在し、Mavenの依存関係に含まれます。アプリケーションソースツリーではなく、独自のリポジトリに配置し、メインアプリケーションのどの部分にも依存しないようにします。

プロジェクトに分割されたアプリケーションのコア部分は、モジュールとしてまとめることができます。通常は、アプリのメインソースフォルダーのサブフォルダーとして配置します。

また、アプリの親POMにはモジュール宣言が含まれます。また、そこにアプリの一般的な依存関係をすべて配置し、ほとんどのビルドプラグインとその構成を宣言します。ここでも、モジュールで再利用できるアプリケーションのバージョンなどのプロパティのグループを配置することをお勧めします。すべてが同じバージョンであり、1つの場所にバージョンがあると、管理がはるかに簡単になります。

ツーリング

あなたが1より大きいチームの場合、Maven依存関係のリポジトリをインストールすることを強くお勧めします。見てArtifactory、ネクサスまたはArchiva。これらに直接インストールするようにPOMファイルを構成できるため、一度実行するとオーバーヘッドが大きくなることはありませんが、正しい場所で正しいjarを使用して依存関係を解決する時間を大幅に節約できます。

ツーリングに関する次の論理的ステップは、ここで継続的インテグレーションシステムです（Jenkinsにはもっとたくさんあります）。テストを実行し、アーティファクトにプッシュするソースのビルドを処理します。これをすべて行うと、コードを実行するだけで残りは機能します。

アプリケーションをwar mavenとしてパッケージ化しているので、 jarファイルやその他の同様の作業をマージすることなく、warの構築を処理し、すべての依存関係を適切な場所に配置できるため、心配する必要はありません。

例

ここでもっと長く続けることができましたが、良い例に勝るものはありません。githubで同様の規模のプロジェクトを探し、pomファイルとフォルダー階層をどのように構築したかを確認してください。1つ以上を見て、いくつかは他のものよりあなたのセットアップによく合います、どれも本当に真実を転生しません、しかしあなたはそれを成し遂げる方法についてのあなたの考えを活気づけるのに十分見つけるべきです。

ジェンキンスを例にとってみましょう：

親の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を取得して適切なプラグインにすることができます。動的なリロードと更新の扉を開くコンポーネントのランタイムライフサイクルをより詳細に制御できます。ただし、コアを大幅に変更する必要があるため、おそらく良い出発点ではありません。ただし、プロジェクトが十分に分離され、すべての部分が希望どおりに分離されると、更新時にアプリケーションを開始および停止することが大きな問題になる場合は、自然な次のステップになります。

モジュールと依存関係の基本的な違いは次のとおりです。

• 理想的には、サブフォルダーとして、モジュールはメインアプリケーションと同じソースツリーに存在します。
• 依存関係はどこでも可能です。

ここで聖書を見つけることができます。

これがお役に立てば幸いです。