私は、Mavenの親子関係について
以下の「パターン」に遭遇しました：http： 
//yuml.me/3f8dd366
この例では、2つのサブモジュールを持つモジュールがあります。モジュールには、2つのサブモジュールを子として認識している親pom「モジュールを構築するための親」があります。
サブモジュールは、この親がそれらを知っていることを知らず、親が「依存関係管理の親」という名前の親であると考えています。依存関係管理、プラグイン構成、共通プロパティなどの一般的な構成があります。
私の質問：
これは「良い」パターンですか？意味は、子供<->親の関係のより直感的なパターンとして、長所/短所がありますか？
注目すべき興味深い点の1つは、アグリゲーターpomです。
これは、「親子」の関係を持たずに、プロジェクトをモジュールごとにグループ化するpomです。アグリゲーターpomには依存関係管理がありません。ビルドのみを管理します。
親pomとアグリゲーターpomの両方を持つことは、Mavenの非常に強力な機能です。
詳細については、こちらをご覧ください。
このMavenページには、複雑なプロジェクト用にpomを設定する方法に関する貴重な洞察もあります。
うーん...私はあなたの写真の用語に同意しないと思います。これが私がこれをどのように見るかです：
モジュールを編成するこの方法は、多くの開発者にとって混乱を招く可能性がありますが、それは物事を行うための合法的な方法です。
とにかく、混乱を招くため、このアプローチはお勧めしません。しかし、時には、それらは代替手段ではありません。
この構成を使用する場合？
サブモジュールの1つ（または複数）にはすでに親があります（つまり、別のプロジェクトで開発されましたが、再構築する必要があります）。<module>マルチモジュールプロジェクトのエントリは相対パスであるため、次のようにすることができます。
<modules>
<module>../../somedir/othermodule</module>
...
</modules>
可能であれば、マルチモジュールを親としても使用することをお勧めします。理由は次のとおりです。
<modules>セクション（親またはサブモジュール<parent>を指定するために醜い相対パスを使用する必要はありません）これは、子を気にせず、プロパティ、dependecyManagement、リポジトリ、pluginManagementなどのすべてが継承するものを含む全社的な構成pomを持つことは実際には良いことです。
多分これはあなたを助けることができます：会社全体の親pom