1. 简介
最近在处理一个SpringBoot多模块项目的时候遇到一个问题，一个pom中只能有一个parent。
使用SpringBoot把SpringBoot设置为parent之后，项目本身就不能做为父项目添加子模块module了。
怎么处理？使用dependencyManagement。
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>${spring.boot.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
dependencyManagement为什么有效？
在SpringBoot中我们经常使用依赖不带版本为什么也可以？
2. dependencyManagement
dependencyManagement其实主要不是为了解决继承问题，而是为了解决依赖版本混乱问题。
dependencyManagement主要用于多模块项目的父项目中。
它的原理是：
当maven发现dependencies中的某个dependency没有设置版本号version，它就会从它的父项目开始，在它的祖先项目中查找dependencyManagement中配置的dependency，直到找到一个有版本号version的依赖，使用该version。
从名字也可以看出dependencyManagement不是为了定义依赖，而是为了管理可能的依赖。有点绕，说个结论，就是如果在子模块中没有使用dependencyManagement定义的依赖，这些依赖的jar包就最终不会被打在输出的jar包中。
3. 为什么使用SpringBoot很多依赖可以不用配置版本号
如果你看SpringBoot的pom就会发现它的父项目是：
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
spring-boot-dependencies中基本啥都没干，就定义了默认的依赖和版本了。
spring-boot-dependencies的pom大致就像下面这个样子的：
![SpringBoot依赖管理]( "SpringBoot依赖管理")
有兴趣的朋友可以看一下这个pom中定义了哪些依赖，及其使用的版本。
4. 依赖管理
像SpringBoot一样，我们在多模块项目中也可以这样玩，首先找出多个模块的共同依赖，然后把他上移到父模块的dependencyManagement，像这样：
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>${spring.boot.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>${guava.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
依赖上移之后，子模块的pom中要移除这些依赖，否则会覆盖定义在父项目中的dependencyManagement中的依赖。
dependencyManagement中的dependencies下的依赖不能直接被子模块继承，必须显式申明。直接在dependencies下的依赖可以被子项目继承。
# 分析哪些依赖使用了但是没有显式定义，哪些依赖定义了没有使用
mvn dependency:analyze
# 分析依赖层级关系
mvn dependency:tree
# 查看有效依赖
mvn help:effective-pom
5. scope
5.1 compile
默认的依赖范围就是compile，没有scope或者scope为comile的依赖表示编译、运行、测试的时候都需要这个依赖的jar包。
5.2 provided
表示环境已经提供了，所以打包的时候就不会将scope为provided的依赖打到输出的jar包中。
最典型的例子是servlet-api，因为这个依赖已经包含在像Tomcat这样的Servlet服务器中了，所以打包的时候就不需要将这个依赖再打包到输出jar包中了。
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>3.0.1</version>
<scope>provided</scope>
</dependency>
5.3 runtime
如果一个依赖的scope为runtime，表示编译的时候不能引用这个依赖的jar包。
还有编译的时候不需要运行的时候需要的jar包？
SPI相关的都是。主要是让面向接口变成，而不要直接去使用实现类，如使用java.sql.Driver，而不是com.mysql.cj.jdbc.Driver。
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>${mysql.version}</version>
<scope>runtime</scope>
</dependency>
5.4 test
scope为test的依赖表示，这个包只是在测试阶段使用，打包的时候这些依赖不会打在输出的jar包中。
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>${junit.version}</version>
<scope>test</scope>
</dependency>
5.5 system
system主要是为了引入一些没有通过maven发布的私有的三方jar包。
这些jar包的特点是：
- 没有发布，所以不能通过maven中央仓库找到
- 是第三方的，所以不能使用自己的私服引入
- 只有jar包
当然你可以把这些jar包加在classpath中，但是对于maven项目来说不好管理。
这个时候，就可以使用scope为system的依赖了，只需要指定这些jar包在系统中的路径就可以了。
<dependency>
<groupId>vip.mycollege</groupId>
<artifactId>tools</artifactId>
<version>1.0.0</version>
<scope>system</scope>
<systemPath>F:/lib/tools.jar</systemPath>
</dependency>
5.6 import
import只能在dependencyManagement的dependency，并且type为pom的依赖中使用。
import主要是为了将依赖管理和依赖定义分开。
例如SpringBoot的dependencyManagement中预定义很多依赖，所以就单独弄了一个spring-boot-dependencies来管理这些依赖。
6. optional
optional是用于控制依赖传递的。
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
<optional>true</optional>
</dependency>
optional设置为true，这个依赖不会被传递，加入在A项目中添加了这个依赖，B项目依赖A，但是B项目不会依赖spring-boot-devtools。
