Maven依赖调解和可选依赖
2017-06-20 16:45
148 查看
Maven依赖调解
Maven引入的传递性依赖机制,一方面大大简化和方便了依赖声明,另一方面,大部分情况下我们只需要关心项目的直接依赖是什么,而不用考虑这些直接依赖会引入什么传递性依赖。但有时候,当传递性依赖造成问题的时候,我们就需要清楚的知道该传递性依赖是从哪条依赖路劲引入的。例如,项目A有这样的依赖关系:A->B->C->X(1.0)、A->D->X(2.0),X是A的传递性依赖,但是两条依赖路径上有两个版本的X,那么哪个X会被Maven解析使用呢?两个版本都解析显然是不对的,因为会造成重复依赖,因此必须选择一个。Maven依赖调解的第一原则是:路劲最近者优先,该例中X(1.0)的路径长度为3,而X(2.0)的路径长度为2,因此X(2.0)会被解析使用。
依赖调节第一原则不能解决所有的问题,如果两条依赖路径的长度是一样的呢?那到底谁被解析使用呢。Maven的依赖调解的第二原则:第一声明者优先。在依赖路径相等的情况下,在POM中依赖声明的顺序决定了谁会先被解析使用,顺序前的先解析使用。
可选依赖
假设有这样一个依赖关系,项目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-connect-java和postgresql这两个依赖为可选依赖,他们只会对当前项目B产生影响,当其他项目依赖于B的时候,这两个依赖不会被传递,因此,当项目A依赖于项目B的时候,如果其实际使用基于MySQL数据库,那么在项目A中就需要显示地声明mysql-connect-java这一依赖。
在理想的情况下,是不应该使用可选依赖的,而是应该为MySQL和PostgreSQL分别创建一个Maven项目,基于同样的groupId分配不同的artifactId,在各自的POM中声明JDBC驱动依赖,而且不使用可选依赖,用户则需要根据选择使用依赖。由于传递性依赖的作用,就不需要在声明JDBC驱动依赖。
相关文章推荐
- Maven依赖调解、 可选依赖、 依赖冲突 排除、 归类依赖、优化依赖
- Maven-05依赖调解
- maven可选依赖(Optional Dependencies)和依赖排除(Dependency Exclusions)
- maven可选依赖(Optional Dependencies)和依赖排除(Dependency Exclusions)
- Maven-06可选依赖
- maven依赖管理中冲突调解及重复类的类加载顺序
- Maven学习笔记十三:Maven坐标和依赖(依赖调解)
- 依赖调解与可选依赖
- Maven开发笔记(二)—— Maven中的可选依赖(Optional Dependencies)和依赖排除(Dependency Exclusions)
- 关于maven可选依赖和排除依赖的学习
- 【maven实战】07-依赖调解
- Maven系列之可选依赖
- maven可选依赖和排除依赖
- maven可选依赖(Optional Dependencies)和依赖排除(Dependency Exclusions)
- 【maven实战】08-可选依赖
- Maven依赖调解
- maven 可选依赖和排除依赖
- maven可选依赖(Optional Dependencies)和依赖排除(Dependency Exclusions)
- Maven依赖调解
- maven可选依赖(Optional Dependencies)和依赖排除(Dependency Exclusions)