シナリオでMavenマルチモジュールプロジェクトを使用する必要がありますか？

Question

状況

私は現在、部分的に相互にやり取りするいくつかのRESTfulサービスを開発するプロジェクトで働いています。例として：

サービスAはサービスBを使用
サービスCは何も使用しません
サービスDはサービスCを使用
ほとんどのサービスは共通のユーティリティプロジェクトを使用します。

サービス間の実際のコード共有はありません。サービスは定義されたRESTful APIに厳密に依存しています。 Utilには、テスト用のヘルパー、セキュリティライブラリ用のヘルパーなどが含まれています。

現在、すべてのプロジェクトは、独自のgitリポジトリに独立しています。開発中に、これが少し厄介な瞬間がありました：

依存関係管理を行うための複数の場所（サービスはサードパーティライブラリへの依存関係を共有します）
すべてのプロジェクトを（maven）個別にリリースする必要があります（個人的にはそれが好きです）
2つのプロジェクト（pull-requests）のため、「between」プロジェクト（サービスの作業とそのためutilの作業）で作業すると、2つのレビューリクエストが発生します。

質問

チームの1人は、上記の問題の解決策として、すべてのgitリポジトリとプロジェクトを1つのgitリポジトリと1つのMavenマルチモジュールプロジェクトにマージすることを提案しました。

自分のアイデアについての不安（コード共有なし、共通の依存関係としてのutilのみ、一部（すべてではない）のサービス間のAPIへの依存など）のほかに、私は知りたいと思います。

この計画の既知の利点/欠点はありますか？

私はそれが悪い議論をするのが好きではありません。

gnat · Accepted Answer

service-a-1.2.3, service-b-1.2.3, service-c-1.2.3などのように、すべてのプロジェクトを（常に、またはほぼ常に）同時にリリースする必要がある場合、手動で行う必要がなく、マルチモジュールプロジェクトが医師からの注文となります。各モジュールのリリースを毎回繰り返します。

そうでなければ、そこに行く前によく考えてください。 service-aのリリースが10件あったためにのみ、10 -同一のリリースがservice-bのようになると、非常に扱いにくく混乱する可能性があります。 aを解放するたびにbを解放します。

私の過去のプロジェクトの1つで、疎結合モジュールの冗長リリースの問題が、マルチモジュールプロジェクトを分割する主な理由でした。

^{「こんにちは。なぜmodule-aの10リリースがあるのですか？ああ、そのうちの2つはmodule-bの変更によるものでした。3つはmodule-cによるものでした。4つはmodule-d。そして、そうです、module-aの変更により、リリースが1回ありました。そうです。 "分割後にこのようなものが消えるのを見るのは非常に安心しました。}

一方、その非常に経験から、複数のモジュールの同期リリースが必要な場合は、間違いなくマルチモジュールプロジェクトに行くことがわかりました。

考えてみてください。関係するモジュールを覚える必要はありません。複雑なリリーススクリプトを設計する必要はありません。mvn -B clean release:prepare release:performを撮影し、しばらくリラックスして、すべてを完璧に調和させることができます。それ以上にはなりません。