1. 坐标
坐标用来唯一定位一个Maven构件：
- GAV(必需)：groupId, artifactId, version
- packaging(可选): 可取值如：
jar(缺省),war,pom,maven-plugin等，其中父项目的packaging通常是pom，只用来声明项目元数据，用到的依赖、插件，以及项目中的子模块等。 - classifier: 不能直接定义，通常用来辅助定义附属构件，如：javadoc、sources构件等。
2. 依赖
在POM的<dependency>元素中，有以下元素可以用来配置依赖：
-
GAV：groupId、artifactId、version。
-
type：对应于被依赖模块的
packaging元素的值，默认是jar。 -
scope:
- compile：默认依赖范围，对编译、测试、运行三种classpath都有效，用于编译、测试、运行阶段都需要用到的依赖；
- test：只对测试classpath有效，编译主代码、运行项目时无法使用的依赖。
- provided：对编译、测试有效，在运行时无效。
- runtime：运行时依赖，对测试、运行classpath有效，在编译主代码时无效；
- import：不会对编译、测试、运行的classpath产生实际影响，
- system：需通过systemPath显式指定依赖的路径，不通过Maven仓库解析，会造成构建的不可移植，不推荐使用。
-
optional：标记依赖是否可选；
-
exclusions：
dependency.exclusions元素用来排除某些传递依赖，通常用来排除传递进来的不合适版本的依赖或根本不需要的依赖。
2.1 管理type为pom类型的依赖
通常一个项目的pom类型的构件用来声明使用到的依赖，为了沿用和管理其声明的所有依赖，通常可以在dependencyManagement元素中如下引用：
<dependencyManagement>
<dependencies>
<dependency>
<artifactId>org.springframework.boot</artifactId>
<groupId>spring-boot-dependencies</groupId>
<version>${spring.boot.version}</version>
<scope>import</scope>
<type>pom</type>
</dependency>
</dependencies>
</dependencyManagement>
以此来保持我们项目使用的依赖和Spring Boot声明的一致。
2.2 依赖范围与classpath关系
| 依赖范围 | 对编译classpath有效 | 对测试classpath有效 | 对运行时classpath有效 | 示例 |
|---|---|---|---|---|
| compile | Y | Y | Y | spring-core |
| provided | Y | Y | - | servlet-api |
| runtime | - | Y | Y | JDBC驱动 |
| test | - | Y | - | JUnit |
| system | Y | Y | - | 本地Maven仓库以外的类库文件 |
2.3 依赖范围与依赖传递的关系
| - | compile | test | provided | runtime |
|---|---|---|---|---|
| compile | compile | - | - | runtime |
| test | test | - | - | test |
| provided | provided | - | provided | provided |
| runtime | runtime | - | - | runtime |
表格说明：
- 最左侧列是第一直接依赖，如A依赖于B，B依赖于C时，A对于B即是第1直接依赖；
- 最上侧行是第2直接依赖，如A依赖于B，B依赖于C时，B对于C即是第2直接依赖；
- 表中其他单元格表示传递依赖的依赖范围，即A传递依赖C的范围。
结论：
- 第2直接依赖的范围是
compile时，传递依赖的范围与第1直接依赖一致； - 第2直接依赖是
test时，依赖不会传递； - 第2直接依赖是
provided时，只传递依赖第1直接依赖也是provided范围的依赖。
3. 依赖调解
- 路径最近者优先，例如：A->B->c->x(1.0)，a->d->x(2.0)，由于a通过第二条路径依赖x的距离更短，因此实际解析使用的是2.0的x。
- 最先声明者优先，例如：a->b->y(1.0)，a->c->y(2.0)，在依赖路径等长时，声明依赖b在声明c之前，则实际解析使用的是y(1.0)。
4. 可选依赖
optional元素是true的依赖是可选依赖。
可选依赖通常用来阻断依赖传递，例如a->b，b->x(可选)、b->y(可选)。
这种情况通常出现在b有多种实现，一种可以使用x，另一种可以使用y的场景。
此时考虑非可选的场景，如果上述3个依赖范围都是compile，那么x和y也应该是a的compile依赖。
然而在可选依赖的场景下，依赖传递被打破，x和y只会对声明可选依赖于他们的b有影响，a并不会传递依赖x和y。
当声明a依赖于b时，就要指明a选择使用b依赖的x还是y，即需要在a中显式的声明依赖x或y。
对于存在可选依赖的场景，应考虑针对每一种可选依赖建立一个独立的模块对外提供功能，从而不使用可选依赖这个概念。
5. 优化依赖
使用列表的形式查看依赖：
mvn dependency:list
使用树形结构查看依赖树：
mvn dependency:tree
分析依赖状况：
mvn dependency:analyze
analyze会列出两类重点关注的依赖：
- 使用但未声明的依赖：指项目中使用到，但是是通过传递依赖传递进来的。
- 声明但未使用的依赖：项目中声明了但未使用的依赖，该命令只列出编译主代码、测试代码需要的依赖，并不会发现执行测试和运行时需要的依赖，所以不应该简单地删除声明了但未使用的依赖。