groupId、artifactId、version共同组成一个坐标来唯一确定该项目在仓库中的位置
当正确配置maven的依赖后，maven会从中央仓库下载对应的依赖
相关信息在已在 ## 2.2 提到
maven打出来的包名一般按照artifactId-version[-classifier].packaging的规约生成
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
网友评论