坐标
坐标用来唯一定位一个Maven构件：
- GAV(必需)：groupId, artifactId, version
- packaging(可选): 可取值如：
jar(缺省),war,pom,maven-plugin等，其中父项目的packaging通常是pom，只用来声明项目元数据，用到的依赖、插件，以及项目中的子模块等。 - classifier: 不能直接定义，通常用来辅助定义附属构件，如：javadoc、sources构件等。
依赖
在POM的<dependency>元素中，有以下元素可以用来配置依赖：
- GAV：groupId、artifactId、version。
- type：对应于被依赖模块的
packaging元素的值。 - scope:
compile：默认依赖范围，对编译、测试、运行三种classpath都有效，用于编译、测试、运行阶段都需要用到的依赖；
test：只对测试classpath有效，编译主代码、运行项目时无法使用的依赖。
provided：对编译、测试有效，在运行时无效。
runtime：运行时依赖，对测试、运行classpath有效，在编译主代码时无效；
import：不会对编译、测试、运行的classpath产生实际影响，
system：需通过systemPath显式指定依赖的路径，不通过Maven仓库解析，会造成构建的不可移植，不推荐使用。
- optional：标记依赖是否可选；
- exclusions：排除某些传递依赖。
管理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声明的一致。
依赖范围与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仓库以外的类库文件 |
依赖范围与依赖传递的关系
| - | 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范围的依赖。
依赖调解
- 路径最近者优先，例如：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)。
可选依赖
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。
对于存在可选依赖的场景，应考虑针对每一种可选依赖建立一个独立的模块对外提供功能，从而不使用可选依赖这个概念。
优化依赖
使用列表的形式查看依赖：
mvn dependency:list使用树形结构查看依赖树：
mvn dependency:tree分析依赖状况：
mvn dependency:analyzeanalyze会列出两类重点关注的依赖：
- 使用但未声明的依赖：指项目中使用到，但是是通过传递依赖传递进来的。
- 声明但未使用的依赖：项目中声明了但未使用的依赖，该命令只列出编译主代码、测试代码需要的依赖，并不会发现执行测试和运行时需要的依赖，所以不应该简单地删除声明了但未使用的依赖。
原文地址：https://www.cnblogs.com/zyon/p/11294226.html