《Maven 实战》读书笔记（三） 坐标和依赖

第五章：坐标和依赖

1.JAVA构件，MAVEN就必须将它们唯一标识，这就是依赖管理的底层基础--坐标。

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

3.maven坐标是通过一些元素定义的，它们是groupId,artifactId,version,packaging,classifier.这5个元素中只packaging是可选的（默认为jar)，而classifier是不能直接定义的。

     (1).groupId,定义当前maven项目隶属的实际项目。

     (2).artifactId,定义实际项目中的一个maven项目（模块），推荐的做法是使用实际的项目名称作为artifactId的前缀。

     (3).version,定义maven当前所处的版本。

     (4).packaging,定义maven项目的打包方式。

     (5).classifier,该元素用来帮助定义构建输出的一些附属构件。

4.项目构件的文件名是与坐标是相对应的，一般规则为"artifactId-version[-classifier].packaging",[-calssifier]表示可选。

5.scope是用来定义依赖范围。

6.依赖的配置

 1 <project>
 2     ......
 3     <dependencies>
 4          <dependency>
 5                <groupId>....</groupId>
 6                <artifactId>......</artifactId>
 7                <version>........</version>
 8                <type>......</type>
 9                <scope>....</scope>
10                <optional>...</optional>
11                <exclusions>
12                     ..........
13                </exclusions>
14          </dependency>
15           ............
16     </dependencies>
17     ......
18 </project>

复制代码

      (1).groupId,artifactId和version：依赖的基本坐标，对于任何一个依赖来说，基本坐标是最重要的，maven根据坐标才能找到需要的依赖。

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

      (3).scope:依赖的范围。

      (4).optional:标记依赖是否可选。

      (5).exclusions：用来排除传递性依赖。

7.依赖范围：是用来控制依赖与这三种classpath（编译classpath，测试classpath，运行classpath）的关系，maven有下面几种依赖范围。

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

     (2)test:测试依赖范围。

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

     (4)runtime:运行时依赖范围。使用该依赖范围，对于测试和运行classpath有效，但是编译时无效。

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

<dependency>
   <goupId>javax.sql</groupId>
   <artifactId>jdbc-stdext</artifactId>
   <version>2.0</version>
   <scope>system</scope>
   <systemPath>${java.home}/lib/rt.jar</systemPath>
</dependency>

       (6)import:导入依赖范围。该依赖范围不会对三种classpath产生实际的影响。

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

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

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

10.可选依赖：假设有这样一个依赖关系，项目A依赖于项目B，项目B依赖于项目X和Y，B对于X和Y的依赖都是可选依赖：A->B,B->X(可选),B->Y(可选）。根据传递性依赖的定义，如果所有这三个依赖的范围都是compile，那么X,Y 就是A的compile范围传递性依赖。然而，由于这里X,Y是可选依赖，依赖不会得以传递。换句话说，X,Y将不会对A有任何影响。项目B的依赖声明见代码清单。关于可选依赖需要说明的一点就是，在理想情况下，是不应该使用可选依赖的。

<project>
   <modelVerion>4.0</modelVersion>
   <groupId>com.juvenxu.mvnbook</groupId>
   <artifactId>project-B</artifactId>
   <version>1.0</version>
   <dependencies>
       <dependency>
           <groupId>mysql</groupId>
           <artifactId>mysql-connector-java</artifactId>
           <version>5.1.10</version>
           <optional>true</optional>
       </dependency>
       <dependency>
           <groupId>postgresql</groupId>
           <artifactId>postagresql</artifactId>
           <version>8.4-701.jdbc3</version>
           <optional>true</optional>
       </dependency>
   </dependencies>
</project>

11.排除依赖。

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

<project>
   <modelVerion>4.0</modelVersion>
   <groupId>com.juvenxu.mvnbook</groupId>
   <artifactId>project-a</artifactId>
   <version>1.0.0</version>
   <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>
</project>

        代码中，项目A依赖于项目B，但是由于一些原因，不想引入传递性依赖C，而是自己显示地声明对于项目C1.1.0版本的依赖。代码中使用exclusions元素声明排除依赖，exclusions可以包含一个或者多个exclusion子元素。

         需要注意的是，声明exclusion的时候只需要groupId,artifactId就能唯一定义某个依赖。

12.归类依赖。通过<properties>元素来定义。

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

     mvn dependency:list

     mvn dependency:tree

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