4、Maven坐标&依赖

groupId、artifactId、version共同组成一个坐标来唯一确定该项目在仓库中的位置

当正确配置maven的依赖后，maven会从中央仓库下载对应的依赖

1.1、依赖(dependency)的具体元素

groupId
artifactId
version
type：可以不声明，默认为jar
scope：可以不声明，默认为compile
optional：表示依赖是否可选
exclusions：排除传递性依赖

1.2、依赖范围(scope)

compile：对于编译、测试、运行三种生命周期的test/main下的源代码都有效，默认为这个
test：只对于测试的生命周期的test目录下的代码有效，如JUnit
provided：对于编译、测试两种生命周期的test/main下的源代码都有效，如servlet-api，容器可以提供这个，所以运行时不用maven提供依赖
runtime：测试和运行时的test/main下的代码有效，如JDBC驱动
system：对于编译、测试两种生命周期的test/main下的源代码都有效，但是要与本机的系统路径绑定，一致性不强，也不是由maven仓库解析
```
<dependency>
  ....
  <scope>system</scope>
  <systemPath>${java.home}/lib/rt.jar</systemPath>
</dependency>
```
import：导入依赖范围，不对依赖的生命周期不会有实际影响

1.3、传递性依赖

A依赖B，B依赖C，那么C就是A的传递性依赖

当第二直接依赖的范围是compile时，传递性依赖的范围与第一直接依赖一致
当第二直接依赖的范围是test时，传递性依赖不会得到传递
当第二直接依赖的范围是provide时，只传递第一直接传递范围为provide的依赖，且范围也是provide
当第二直接依赖的范围是runtime时，传递性依赖范围与第一直接依赖范围一致，但compile不一样，传递依赖为runtime

1.4、依赖调解

有如下依赖路径：

A -> B -> C -> X (1.0)

A -> D -> X (2.0)

两条路径都引用了X，此时Maven会选用最短路径原则，那么第二条路径会被运用

有如下依赖路径：

A -> C -> X (1.0)

A -> D -> X (2.0)

两条路径都引用了X，且路径长度一致，此时Maven会选用最先声明原则，在pom文件先声明的依赖会被启用，那么第一条路径会被运用

1..5、排除传递性依赖

排除依赖只需要groupId和artifactId

<dependency>
    ....
    <exclusions>
        <exclusion>
            <groupId>···</groupId>
            <artifactId>···</artifactId>
        </exclusion>
    </exclusions>
</dependency>

1.6、依赖归类

同一项目的不同包可能优势用的版本是一样的，我们可以用Maven的属性来进行统一管理

<properties>
    <a.version>1.0.0</a.version>
</properties>

然后在dependency的version中使用${a.version}引用即可

1.7、优化依赖

Maven会解析项目的直接依赖和传递依赖，并且正确判断依赖范围，可以调节依赖冲突来保证只有一个版本正确引用，完成后的依赖叫已解析依赖

查看依赖列表
```
cmd:mvn dependency:list
```
查看依赖树状图
```
cmd:mvn dependency:tree
```
分析项目依赖使用情况
```
cmd:mvn dependency:analyze
```
可以查看依赖是否被使用等等

此处怀疑只能看到scope为compile而没被用到的依赖，scope为provided但实际在项目中要用到的依赖同样会显示unused dependency