Maven多模块的2种依赖管理策略

在Maven多模块的时候，管理依赖关系是非常重要的，各种依赖包冲突，查询问题起来非常复杂，于是就用到了<dependencyManagement>，

示例说明，

在父模块中：

<dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>mysql</groupId>
                <artifactId>mysql-connector-java</artifactId>
                <version>5.1.44</version>
            </dependency>

        </dependencies>
</dependencyManagement>

那么在子模块中只需要声明groupId和artifactId即可，如：

 <dependencies>
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
        </dependency>
 </dependencies>

说明：

使用dependencyManagement可以统一管理项目的版本号，确保应用的各个项目的依赖和版本一致，不用每个模块项目都弄一个版本号，不利于管理，当需要变更版本号的时候只需要在父类容器里更新，不需要任何一个子项目的修改；如果某个子项目需要另外一个特殊的版本号时，只需要在自己的模块dependencies中声明一个版本号即可。子类就会使用子类声明的版本号，不继承于父类版本号。

与dependencies区别：

1)Dependencies相对于dependencyManagement，所有声明在dependencies里的依赖都会自动引入，并默认被所有的子项目继承。

2)dependencyManagement里只是声明依赖，并不自动实现引入，因此子项目需要显示的声明需要用的依赖。如果不在子项目中声明依赖，是不会从父项目中继承下来的；只有在子项目中写了该依赖项，并且没有指定具体版本，才会从父项目中继承该项，并且version和scope都读取自父pom;另外如果子项目中指定了版本号，那么会使用子项目中指定的jar版本。

当然了，在项目的实际开发中，我们常见的有2种思路来进行这种依赖的管理：

1.在父pom中使用dependencyManagement标签,进行jar包版本的统一管理，当需要变更版本号的时候只需要在父类容器里更新，不需要任何一个子项目的修改，大部分项目使用这种方式，例如开发的谷粒教育。

2.将公共的依赖抽取到common模块，然后其它模块都依赖common模块，在common模块实现对公共依赖的管理，各个模块独有的依赖配置在各个模块的pom文件中，例如开发的谷粒商城。这两种模式都可以，可根据情况自行选择。