Maven 实战 02 依赖

坐标

maven定义了这样一组规则：世界上任何一个构件都可以使用maven坐标唯一标识，maven坐标的元素包括

groupId       定义当前maven项目隶属的实际项目

artifactId     定义实际项目中的一个maven项目（模块），

version          定义当前所处的版本

packaging     定义项目的打包方式。默认为jar

classifier       该元素用来帮助定义构建输出的一些附属构件，如nexus-index-2.0.0-javadoc.jar中，javadoc即为classifier，附属构建不是项目直接生成的，而是由附加插件帮助生成的

---

依赖的配置

          <dependency>
                <groupId>....</groupId>
                <artifactId>......</artifactId>
                <version>........</version>
                <type>......</type>
                <scope>....</scope>
                <optional>...</optional>
                <exclusions>
                     ..........
                </exclusions>
          </dependency>

groupId,artifactId和version：依赖的基本坐标，对于任何一个依赖来说，基本坐标是最重要的，

type:依赖的类型，对于项目坐标定义的packaging。大部分情况下，该元素不必声明，其默认值为jar

scope:依赖的范围

optional:标记依赖是否可选

exclusions：用来排除传递性依赖

---

依赖范围：是用来控制依赖与这三种classpath（编译classpath，测试classpath，运行classpath）的关系

compile:编译依赖范围。如果没有指定，就会默认使用该依赖范围。使用该依赖范围，对于编译，测试，运行三种classpath都有效

test:测试依赖范围

provided:已提供依赖范围。使用该依赖范围，对于编译和测试classpath有效，但运行时无效(servlet-api)

runtime:运行时依赖范围。使用该依赖范围，对于测试和运行classpath有效，但是编译时无效(jdbc驱动，编译时只需JDK提供的JDBC接口,运行时需要具体实现类)

system:系统依赖范围。该依赖与三种classpath的关系，和provided依赖范围完全一致。但是，使用system范围依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此依赖不是通过maven仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，一次谨慎使用。systemPath可以引用环境变量

---

传递性依赖：account-mail有一个compile范围的spring-core依赖，spring-core有一个compile范围的commons-logging依赖，那么commons-logging就会成为account-mail的compile范围依赖

---

依赖调解：maven引入的传递性依赖机制，一方面大大简化和方便了依赖声明，另一方面大部分情况下我们只需要关心项目直接依赖的是什么，而不用考虑这些依赖会引入什么传递性依赖。但有时候，当传递依赖造成问题的时候，我们需要清楚地知道该传递性依赖是从哪条依赖路径引入的

maven依赖调解的两个原则。（1）第一原则是：路径最近者优先。（2）第二原则是：第一声明者优先。在依赖路径长度相等的前提下，在pom依赖声明的顺序决定了谁会解析使用，顺序最靠前的那个依赖优胜

A->B->C->X(1.0)、A->D->X(2.0)

X(1.0)的路径为3，而X(2.0)的路径为2，因此X(2.0)会被解析。

A->B->Y(1.0)、A->C->Y(2.0)

对应路径长度相等的，在POM中依赖声明的顺序决定谁会被解析

---

传递性依赖给项目隐式地引入了很多依赖，这极大地简化了项目的依赖管理，但是有时候这种特性也会带来问题。比如，当前项目有一个第三方依赖，而这个第三方依赖由于某些原因依赖了另外一个类库的SNAPSHOT的版本，那么这个SNAPSHOT就会成为当前项目的传递性依赖，而SNAPSHOT的不稳定性会影响到当前项目。这时需要排除该SNAPSHOT，并且在当前项目中声明该类库某个正式发布版本

<dependencies>

       <dependency>

           <groupId>com.juvenxu.mvnbook</groupId>

           <artifactId>project-b</artifactId>

           <version>1.0.0</version>

           <exclusions>

             <exclusion>

                 <groupId>com.juvencu.mvnbook</groupId>

                 <artifactId>project-c</artifactId>

             </exclusion>

           </exclusions>

       </dependency>

       <dependency>

          <groupId>com.juvencu.mvnbook</groupId>

          <artifactId>project-c</artifactId>          

          <version>1.1.0</version>

       </dependency>

   </dependencies>

---

通过${变量名}来引用

声明一个常量信息，所有用到的地方都用这个常量

    <properties>

    <springversion>2.5.6</springversion>

    <junitversion>2.5.6</junitversion>

    </properties>

   <version> ${springversion}</version>

---

优化依赖：maven会自动解析所有项目的直接依赖和传递性依赖，并且根据规则正确判断每个依赖的范围。对于一些依赖冲突，也能进行调节，以确保任何一个构件只有唯一的版本在依赖中存在。在这些工作之后，最后得到的那些依赖被称为解析依赖。运行下面两条命令分别可以查看当前项目的已解析依赖。

mvn dependency:list

mvn dependency:tree

使用mvn dependency:list和mvn dependency:tree可以帮助我们详细了解项目中所有依赖的具体信息。在此基础上，还有dependency:analyze工具可以帮助分析当前项目的依赖，但是该工具只会分析编译主代码和测试代码所需要用到的依赖，一些执行测试和运行时需要的依赖它就发现不了。

转载于:https://my.oschina.net/Yaland/blog/424941