すべてのプロジェクトの依存関係をすべてのサブ プロジェクトに含めることは非常に非効率的です。これを行うと、すべてのサブ プロジェクトのビルドに不要な依存関係が効果的に持ち込まれます。もう1つの問題は、サブプロジェクト間の依存関係がある場合、つまりサブプロジェクトaがサブプロジェクトbに依存している場合、mavenが解決できないサイクル依存関係に簡単に陥る可能性があることです。
プロジェクト全体で依存関係のバージョンの一貫性を保つために、maven のアプローチは、プロジェクトの親 pom の依存関係管理セクションを利用することです。したがって、親 pom の依存関係管理セクションですべての依存関係のバージョンのみを設定します。サブプロジェクトの pom には、グループ ID とアーティファクト ID のみが記載されています。必要でない限り、サブプロジェクトの pom でバージョンタグを使用しないでください (つまり、サブプロジェクトがプロジェクトの残りの部分とは異なる依存関係の特定のバージョンを必要とする場合)。
すべての子が同じ依存関係を宣言する場合は、代わりに親でその依存関係を宣言することをお勧めします。すべてのプロジェクトが依存関係の一貫したバージョンを使用するようにすることについては、あなたは正しいです。
同じ依存関係の異なるバージョンを使用できる場合、Maven 開発者が子プロジェクトで依存関係を宣言できるようにしたのはなぜですか? プロジェクトでローカルに宣言された依存関係の利点は、兄弟プロジェクトとは異なる場合、親がすべての子のすべての依存関係を宣言するように制限するよりも優れていると考えていたと思います。
クラス内の異なるスコープで宣言された変数のように考えてください。メソッドにプライベート変数がある場合、それは 1 つのメソッドでのみ使用されることがわかっており、コード ベース全体を心配する必要なく、必要に応じて変更できます。クラスにプライベート フィールドがある場合、他のファイルではなく、そのクラスでのすべての使用法に注意する必要があります。パブリック変数がある場合は、アイデアが得られます。依存関係は同じです。単一のプロジェクトに対して宣言されている場合、単一のプロジェクトでのみ使用/必要とされていることを確認できます。さらに、同じ親の別の子プロジェクトを構築している場合は、存在する必要はありません。
WAR を構築する場合、その通りです。異なる子プロジェクトで同じ依存関係の異なるバージョンを使用すると、最終的なアーティファクトに不満を抱く可能性があります。プロジェクト間でバージョン番号が混在していても問題にならず、実際には望ましいプロジェクト タイプとビルド サイクルがあることに注意してください。
また、maven の親 pom ファイルも親を持つことができることを忘れないでください。これにより、2 つのレベルだけでなく、より多くの層の階層が可能になります。すべての子プロジェクトが最上位の親プロジェクトの pom ファイルで依存関係を宣言する必要があるとしたら、ばかげていると思います。