一 、说明
我们知道maven能帮我们管理jar包，那么它是怎么管理的呢？
二 、什么是坐标？
1、数学中的坐标
- 在平面上，使用 X 、Y 两个向量可以唯一的定位平面中的任何一个点
- 在空间中，使用 X、Y、Z 三个向量可以唯一的定位空间中的任意一个点
2、Maven 中的坐标
俗称 gav：使用下面三个向量子仓库中唯一定位一个 Maven 工程
在项目中的 pom.xml 文件中，我们可以看到下面gav的定义：
- groupid:公司或组织域名倒序
<groupid>com.wener</groupid> - artifactid:模块名，也是实际项目的名称
<artifactid>webapp</artifactid> - version:当前项目的版本
<version>0.0.1-SNAPSHOT</version> <version>0.0.1-RELEASE</version>
备注:
在企业的私服中，会存在snapshot快照仓库和release发布仓库，snapshot快照仓库用于保存开发过程中的不稳定版本，release正式仓库则是用来保存稳定的发行版本。
maven会根据模块的版本号(pom文件中的version)中是否带有“-SNAPSHOT”(注意这里必须是全部大写)来判断是快照版本还是正式版本。如果是快照版本，那么在mvn deploy时会自动发布到私服的快照版本库中;如果是正式发布版本，那么在mvn deploy时会自动发布到正式版本库中
三、什么是依赖？
1、概念
如果我们想要在工程中引入某个jar 包，只需要在
pom.xml中引入其jar 包的坐标即可
2、依赖配置
配置信息
<project> <dependencies> <dependency> <groupId></groupId> <artifactId></artifactId> <version></version> <type>...</type> <scope>...</scope> <optional>...</optional> <exclusions> <exclusion> <groupId>...</groupId> <artifactId>...</artifactId> </exclusion> </exclusions> </dependency> </dependencies> </project>
配置说明
- dependencies
一个 pom.xml 文件中只能存在一个这样的标签。用来管理依赖的总标签 - dependency
包含在dependencies标签中，可以有无数个，每一个表示一个依赖 - groupId,artifactId,version：(必要)
依赖的基本坐标，对于任何一个依赖来说，基本坐标是最重要的，Maven根据坐标才能找到需要的依赖。 - type(可选)
依赖的类型，对应于项目坐标定义的packaging。大部分情况下，该元素不必声明，其默认值是jar。 - scope(可选)
依赖的范围，默认值是 compile - optional(可选)
标记依赖是否可选 - exclusions(可选)
用来排除传递性依赖,例如jar包冲突
3、依赖的范围(scope)
- 说明
依赖范围就是来控制 classpath(编译、测试、运行) 的关系，maven 的依赖范围有如下几种 - 可选值
- compile
编译依赖范围。如果没指定，就会默认指定该范围。此依赖范围的 maven 依赖对编译、测试、运行三种 classpath 都有效。 - test
测试依赖范围。只对测试 classpath 有效。如，Junit。 - provided
已提供依赖范围。此依赖范围对编译和测试 classpath 有效。如， servlet-api，编译和测试的时候需要，但在项目运行的时候，容器会提供，就不需要重复的引入。 - runtime
运行时依赖范围。此依赖范围对测试和运行 classpath 有效。如，jdbc 驱动实现，代码编译只需要 jdk 提供的接口就好，测试和运行才需要实际的 jdbc 驱动。 - system：
系统范围依赖。此依赖范围对编译和测试 classpath 有效。不要使用。
- compile
- 示意图
依赖范围 编译classpath有效 测试classpath有效 运行时classpath有效 例子 compile Y Y Y spring-context test N Y N Junit provided Y Y N servlet-api runtime N Y Y mysql驱动 system Y Y N 本地的，maven仓库之外的类库文件
4、maven对传递依赖的解析规则。
第一原则：路径最近者优先
如：A->B->C->X(1.0), A->D->X(2.0),对于X构件有2个版本1.0和2.0，因为X（1.0）的依赖长度为3，而X（2.0）的长度为2，所以maven会解析X（2.0）做为当前构件的依赖。
第二原则：第一声明者优先
如果第一原则不能解析依赖。如2个依赖的构件的依赖长度是一样的情况。如A->B->X(1.0)和A->C->X(2.0),X的依赖长度都是2，这时，maven会根据X1.0和X2.0在构件中声明的顺序来决定解析哪个版本。
1、当第二依赖的范围是compile的时候，传递性依赖的范围与第一直接依赖的范围一致。
2、当第二直接依赖的范围是test的时候，依赖不会得以传递。
3、当第二依赖的范围是provided的时候，只传递第一直接依赖范围也为provided的依赖，且传递性依赖的范围同样为 provided；
4、当第二直接依赖的范围是runtime的时候，传递性依赖的范围与第一直接依赖的范围一致，但compile例外，此时传递的依赖范围为runtime；
5、依赖调解
说明
在dependency元素下增加元素exclusions元素。声明一些需要排除的传递性依赖。然后增加对传递性依赖的确切版本的依赖来解决jar版本冲突的问题。解决的方案有两种一种是手动解决, 另外一种是通过maven helper 插件解决
解决方案
手动法
- 首先分析冲突jar包的依赖路径，使用命令：
mvn dependency:tree -Dverbose -Dincludes=commons-logging:commons-loggging，该命令将打印出所有依赖了groupId和artifactId都为commons-logging的jar包的依赖路径。 - 在两个冲突的版本中，选择一个所需的版本
- 在pom.xml文件中将冲突的依赖排除，可使用某冲突jar包
maven helper 插件
- IDEA中安装该插件，选择confilcts，会列出有冲突的jar，右侧在要排除的版本上右键点击Exclude
