maven build dependency management and dependency scope

I encountered a problem in my work today. I need to modify the framework source code developed by the company a little during development. I want to modify the version number of the changed module separately to facilitate local project reference testing. In the original pom file, <dependency> is from the parent node. The public dependency version is referenced in dependencyManagement>, now using <version> </ version> to reference the changed version alone does not cover the version declared in <dependencyManagement>, weird, we are digging once again to learn the maven dependency management principles .

The above problem is similar to the springboot framework when building a project. They all use <dependencyManagement> to manage the common dependencies between multiple modules. Taking the springboot project as an example, when using springboot, other pom dependencies are not configured with version The version number, maven will default to <dependencyManagement> to find the version of the dependency package declaration, and automatically obtain it, as shown below:

If you want to specify the version number yourself, a common way is to declare the version with dependency in the module, the sound in dependencyManagement will be overwritten. See the following figure to see that the introduced spring-boot-starter-freemarker version is consistent:

 

Common way two: Use <peoperties> to specify the version number to override the version in parent, provided that the dependency needs to be in the list specified by dependencies, and specifying the introduction of dependencies also takes effect.

I have read on the Internet that <dependencyManagement> in dependency delivery takes precedence over delivery dependency, and it is only for the same version number as the declared version number, which does not apply to the scenario of different version numbers I encountered.

Then put the problem point on the dependency range and conduct investigation. Maven's commonly used 6 dependency ranges:

compile, the default scope, compile dependencies are available for all classpaths of the project.

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依赖管理配置，在我的项目中发现，既使用了这种非继承的方式引用了公共依赖，又使用了继承父模块中也重复引了一次公共依赖，导致了本文开头描述问题，前人挖坑，后人乘凉，感谢前辈们又小子学习了新知识，内牛满面。