今日の仕事で問題が発生しました。開発中に会社が開発したフレームワークのソースコードを少し変更する必要があります。変更したモジュールのバージョン番号を個別に変更して、ローカルプロジェクトの参照テストを容易にしたいと考えています。パブリック依存関係バージョンはdependencyManagement>で参照されていますが、<version> </ version>を使用して変更されたバージョンのみを参照すると、<dependencyManagement>で宣言されたバージョンはカバーされません。
上記の問題は、プロジェクトをビルドするときのspringbootフレームワークに似ています。それらはすべて、<dependencyManagement>を使用して、複数のモジュール間の共通の依存関係を管理します。例として、springbootプロジェクトを使用すると、他のpom依存関係はバージョンで構成されませんバージョン番号、mavenはデフォルトで<dependencyManagement>になり、依存パッケージ宣言のバージョンを見つけて、以下に示すように自動的に取得します。
次に、問題点を依存範囲に置き、調査を行いますMavenで一般的に使用される6つの依存範囲：
コンパイル、デフォルトのスコープ、コンパイルの依存関係は、プロジェクトのすべてのクラスパスで使用できます。
provided，和compile范围很类似，但provided范围表明你希望由JDK或者某个容器提供运行时依赖。
runtime，runtime范围表明编译时不需要依赖，而只在运行时依赖。
test，test范围表明使用此依赖范围的依赖，只在编译测试代码和运行测试的时候需要，应用的正常运行不需要此类依赖。
system，系统范围与provided类似，不过你必须显式指定一个本地系统路径的jar，此类依赖应该一直有效，Maven也不会去仓库中寻找它。
上面6种都是单独作用一个依赖，我想引入的包使用的是默认compile作用范围，观察不出任何异常，
最后关注到Maven2.0.9以后引入的import作用域，该scope是为了解决maven不能多继承的问题，避免层层依赖下来，父模块中包含大量不需要的依赖。
使用import，把dependencyManagement放到单独的专门用来管理依赖的pom中，然后在需要使用依赖的模块中通过import scope依赖，就可以引入dependencyManagement，与我当前开发的项目设计完全相同，使用import可以使用非继承的方式引入自定义的dependencyManagement依赖管理配置，在我的项目中发现，既使用了这种非继承的方式引用了公共依赖，又使用了继承父模块中也重复引了一次公共依赖，导致了本文开头描述问题，前人挖坑，后人乘凉，感谢前辈们又小子学习了新知识，内牛满面。