Encontré un problema en mi trabajo hoy. Necesito modificar un poco el código fuente del marco desarrollado por la compañía durante el desarrollo. Quiero modificar el número de versión del módulo modificado por separado para facilitar las pruebas de referencia del proyecto local. En el archivo pom original, <dependency> es de La versión de dependencia pública está referenciada en dependencyManagement>, ahora usando <version> </ version> para hacer referencia a la versión modificada por sí sola no cubre la versión declarada en <dependencyManagement> .
El problema anterior es similar al framework springboot cuando se construye un proyecto. Todos usan <dependencyManagement> para administrar las dependencias comunes entre múltiples módulos. Tomando el proyecto springboot como ejemplo, cuando se usa springboot, otras dependencias pom no están configuradas con la versión El número de versión, maven, estará predeterminado en <dependencyManagement> para encontrar la versión de la declaración del paquete de dependencia y obtenerla automáticamente, como se muestra a continuación:
Luego ponga el punto problemático en el rango de dependencia y realice una investigación. Los 6 rangos de dependencia comúnmente utilizados por Maven:
compilar, el alcance predeterminado, las dependencias de compilación están disponibles para todos los classpaths del proyecto.
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依赖管理配置，在我的项目中发现，既使用了这种非继承的方式引用了公共依赖，又使用了继承父模块中也重复引了一次公共依赖，导致了本文开头描述问题，前人挖坑，后人乘凉，感谢前辈们又小子学习了新知识，内牛满面。