【Maven】Maven实战总结(二) Maven中的依赖

大家好，欢迎来到IT知识分享网。

背景

　　这篇文档主要围绕依赖进行展开，介绍Maven中依赖的相关技术点

Maven坐标

　　Maven坐标为各种构件引入了秩序，任何一个构件都必须明确定义自己的坐标，而一组Maven坐标是通过一些元素定义的，它们是groupId、artifactId、version、packaging、classifier。先看一组坐标定义，如下：

＜groupId＞org.sonatype.nexus＜/groupId＞
＜artifactId＞nexus-indexer＜/artifactId＞
＜version＞2.0.0＜/version＞
＜packaging＞jar＜/packaging＞

　　坐标元素详解
　　　　groupId：定义当前Maven项目隶属的实际项目依赖相关标签
　　　　artifactId：该元素定义实际项目中的一个Maven项目（模块）
　　　　version：该元素定义Maven项目当前所处的版本
　　　　packaging：该元素定义Maven项目的打包方式。首先，打包方式通常与所生成构件的文件扩展名对应，如上例中packaging为jar，最终的文件名为nexus-indexer-2.0.0.jar，而使用war打包方式的Maven项目，最终生成的构件会有一个.war文件，不过这不是绝对的。当不定义packaging的时候，Maven会使用默认值jar
　　　　classifier：该元素用来帮助定义构建输出的一些附属构件(使用的比较少)

　　　　上述5个元素中，groupId、artifactId、version是必须定义的，packaging是可选的（默认为jar），而classifier是不能直接定义的

依赖的配置　　　　

　　　　project下的dependencies可以包含一个或者多个dependency元素，以声明一个或者多个项目依赖。每个依赖可以包含的元素有
　　　　groupId、artifactId和version：这三个是核心元素，最重要
　　　　type：依赖的类型对应于项目坐标定义的packaging。大部分情况下，该元素不必声明，其默认值为jar。
　　　　scope：依赖的范围
　　　　optional：标记依赖是否可选
　　　　exclusions：用来排除传递性依赖

依赖的范围

　　　　依赖范围就是用来控制依赖与这三种classpath（编译classpath、测试classpath、运行classpath）的关系，Maven有以下几种依赖范围：

　　　　compile：编译依赖范围。如果没有指定，就会默认使用该依赖范围。使用此依赖范围的Maven依赖，对于编译、测试、运行三种classpath都有效。典型的例子是spring-core，在编译、测试和运行的时候都需要使用该依赖。
　　　　test：测试依赖范围。使用此依赖范围的Maven依赖，只对于测试classpath有效，在编译主代码或者运行项目的使用时将无法使用此类依赖。典型的例子是JUnit，它只有在编译测试代码及运行测试的时候才需要。
　　　　provided：已提供依赖范围。使用此依赖范围的Maven依赖，对于编译和测试class-path有效，但在运行时无效。典型的例子是servlet-api，编译和测试项目的时候需要该依赖，但在运行项目的时候，由于容器已经提供，就不需要Maven重复地引入一遍。
　　　　runtime：运行时依赖范围。使用此依赖范围的Maven依赖，对于测试和运行class-path有效，但在编译主代码时无效。典型的例子是JDBC驱动实现，项目主代码的编译只需要JDK提供的JDBC接口，只有在执行测试或者运行项目的时候才需要实现上述接口的具体JDBC驱动。
　　　　system：系统依赖范围。该依赖与三种classpath的关系，和provided依赖范围完全一致。但是，使用system范围的依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，因此应该谨慎使用。systemPath元素可以引用环境变量，如：

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

　　　　import（Maven 2.0.9及以上）：导入依赖范围。该依赖范围不会对三种classpath产生实际的影响

传递性依赖

　　　　//TODO

依赖调解

　　　　第一原则是：路径最近者优先
　　　　例如：项目A有这样的依赖关系：A-＞B-＞C-＞X（1.0）、A-＞D-＞X（2.0），X是A的传递性依赖，但是两条依赖路径上有两个版本的X
　　　　该例中X（1.0）的路径长度为3，而X（2.0）的路径长度为2，因此X（2.0）会被解析使用。
　　　　第二原则：第一声明者优先
　　　　例如：A-＞B-＞Y（1.0）、A-＞C-＞Y（2.0），Y（1.0）和Y（2.0）的依赖路径长度是一样的，都为2，在依赖路径长度相等的前提下，在POM中依赖声明的顺序决定了谁会被解析使用，顺序最靠前的那个依赖优胜。该例中，如果B的依赖声明在C之前，那么Y（1.0）就会被解析使用。

可选依赖

　　　　假设有这样一个依赖关系，项目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实现了两个特性，其中的特性一依赖于X，特性二依赖于Y，而且这两个特性是互斥的，用户不可能同时使用两个特性。比如B是一个持久层隔离工具包，它支持多种数据库，包括MySQL、PostgreSQL等，在构建这个工具包的时候，需要这两种数据库的驱动程序，但在使用这个工具包的时候，只会依赖一种数据库。

　　　上述XML代码片段中，使用＜optional＞元素表示mysql-connector-java和postgresql这两个依赖为可选依赖，它们只会对当前项目B产生影响，当其他项目依赖于B的时候，这两个依赖不会被传递。因此，当项目A依赖于项目B的时候如果其实际使用基于MySQL数据库，那么在项目A中就需要显式地声明mysql-connector-java这一依赖
　　　延伸一下，这里有个场景，例如我们在SpringBoot微服务中，需要引入其他项目的API包，如果某些同事不注意，讲MysQL依赖传递到了API包，由于引入了API包，启动项目时，会出现无法启动的问题，这里是否可以考虑使用optional可选依赖去处理这个问题

参考

　　Maven实战 (许晓斌)