基になる (読み取り: 非 Web 向き) Thrift サービスを呼び出すフロントエンド (読み取り: Web 向き) HTTP API に基づく分散アプリケーションを構築しています。
例として、私は持っているかもしれません：
個々のサービスはすべてコア サービスに依存しており、HTTP Web 向け API も同様です。私はこれを現在マルチモジュールプロジェクトとして持っていますが、それぞれを別々にしたいと思います（そして、独自のリポジトリで追跡します-マルチモジュールビルドでこれを行うことができることはわかっています）。
tl;dr -
モジュール (core-service) を個別にビルドしてから maven リポジトリにプッシュする (そして、他のプロジェクトに jar として含める) ことは、一般的なビルド方法ですか?マルチモジュールプロジェクト?
個人的には、 Maven Release Pluginを使用している場合、すべてのモジュールを一緒にリリースする必要がある ため、マルチモジュール プロジェクトは避けようとしています。
これは便利なように聞こえるかもしれませんが、モジュールの 1 つにバグ修正リリースを行う必要がある場合に問題が発生します。つまり、バグ修正を含むモジュールだけでなく、すべてのモジュールをリリースすることになり、バージョンを上げていないにもかかわらず、バージョンを上げてしまいます。かわった。
マルチモジュール プロジェクトで CI を実行している場合もヒットします。ビルドは通常、ルート pom からすべてのモジュールに対して実行されますが、特定のモジュールで作業している場合は、それらのビルドのヒットを被ることになります。変更されていないため、モジュール化が提供するはずだった利点の一部が失われています。
したがって、独立したモジュールを使用しますが、これが重要な点ですが、それぞれが使用する共通の「依存関係」pom を作成します。
「依存関係」pom は、プロジェクト全体のすべての依存関係を標準化する pom であり、それらの依存関係がdependencyManagementセクションではなくセクションで指定されるという点で異なりますdependencies(標準のプラグイン構成などもセットアップします)。これにより、プロジェクト pom は依存関係 pom を親として指定し、必要な依存関係からバージョンを差し引いて宣言できます。バージョンは「依存関係」pom から取得され、プロジェクト間で標準化されます。
すべてをビルドできるか心配な場合は、単純なバッチ ファイルを使用してこれを実現できます。
原則として、プロジェクトを可能な限り独立して進化させることは常に良いことです。ただし、これは技術的な問題ではなく、組織の問題です。結局のところ、プロジェクト構造は組織と一致している必要があります。
これは要するに、プロジェクトを別々に保ち、依存するプロジェクトが別の人によって管理されている場合、または別の時期にリリースすることが理にかなっている場合、ローカル リポジトリ マネージャーを使用して依存関係を管理することになります。それ以外の場合は、マルチモジュール プロジェクト構造を使用する方がよいでしょう。
私たちのプロジェクトでは、一種の中間の選択を行いました: マルチモジュール構造を持っていますが、すべてのプロジェクトは独立した Subversion リポジトリに存在するため、個別に分岐することができ、アグリゲーター プロジェクトを使用して選択します。svn:externals特定の顧客向けにカスタマイズされたリリースを作成するために、さまざまなブランチのプロジェクトを組み合わせる方法。
欠点は、同様の構造を維持するのが複雑で時間がかかることです。これらのタスクを部分的に自動化するために、大量のスクリプトを開発しました。Maven release pluginは Subversion 外部によってフックされたモジュールを処理できないため、これは特に面倒です。