4、Maven坐标的概念以及依赖管理

一 、说明

我们知道maven能帮我们管理jar包，那么它是怎么管理的呢？

二 、什么是坐标？

1、数学中的坐标

1. 在平面上，使用 X 、Y 两个向量可以唯一的定位平面中的任何一个点
2. 在空间中，使用 X、Y、Z 三个向量可以唯一的定位空间中的任意一个点

2、Maven 中的坐标

俗称 gav：使用下面三个向量子仓库中唯一定位一个 Maven 工程

在项目中的 pom.xml 文件中，我们可以看到下面gav的定义：

1. groupid:公司或组织域名倒序

   com.wener
   

2. artifactid:模块名，也是实际项目的名称

   webapp
   

3. version:当前项目的版本

   0.0.1-SNAPSHOT
   0.0.1-RELEASE
   

备注:
在企业的私服中，会存在snapshot快照仓库和release发布仓库，snapshot快照仓库用于保存开发过程中的不稳定版本，release正式仓库则是用来保存稳定的发行版本。
maven会根据模块的版本号(pom文件中的version)中是否带有“-SNAPSHOT”(注意这里必须是全部大写)来判断是快照版本还是正式版本。如果是快照版本，那么在mvn deploy时会自动发布到私服的快照版本库中;如果是正式发布版本，那么在mvn deploy时会自动发布到正式版本库中

三、什么是依赖？

1、概念

如果我们想要在工程中引入某个jar 包，只需要在pom.xml 中引入其jar 包的坐标即可

2、依赖配置

配置信息

2. 
       
           
               
               
               
               ...
               ...
               ...
               
                   
                     ...
                     ...
                   
             
           
         
   
   

配置说明

1. dependencies
   一个 pom.xml 文件中只能存在一个这样的标签。用来管理依赖的总标签
2. dependency
   包含在dependencies标签中，可以有无数个，每一个表示一个依赖
3. groupId,artifactId,version：(必要)
   依赖的基本坐标，对于任何一个依赖来说，基本坐标是最重要的，Maven根据坐标才能找到需要的依赖。
4. type(可选)
   依赖的类型，对应于项目坐标定义的packaging。大部分情况下，该元素不必声明，其默认值是jar。
5. scope(可选)
   依赖的范围，默认值是 compile
6. optional(可选)
   标记依赖是否可选
7. exclusions(可选)
   用来排除传递性依赖,例如jar包冲突

3、依赖的范围(scope)

1. 说明
   依赖范围就是来控制 classpath(编译、测试、运行) 的关系，maven 的依赖范围有如下几种
2. 可选值
   • compile
     编译依赖范围。如果没指定，就会默认指定该范围。此依赖范围的 maven 依赖对编译、测试、运行三种 classpath 都有效。
   • test
     测试依赖范围。只对测试 classpath 有效。如，Junit。
   • provided
     已提供依赖范围。此依赖范围对编译和测试 classpath 有效。如， servlet-api，编译和测试的时候需要，但在项目运行的时候，容器会提供，就不需要重复的引入。
   • runtime
     运行时依赖范围。此依赖范围对测试和运行 classpath 有效。如，jdbc 驱动实现，代码编译只需要 jdk 提供的接口就好，测试和运行才需要实际的 jdbc 驱动。
   • system：
     系统范围依赖。此依赖范围对编译和测试 classpath 有效。不要使用。
3. 示意图

   依赖范围	编译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