本文主要是介绍《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工具可以帮助分析当前项目的依赖，但是该工具只会分析编译主代码和测试代码所需要用到的依赖，一些执行测试和运行时需要的依赖它就发现不了。
这篇关于《Maven 实战》读书笔记（三） 坐标和依赖的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
