【Maven】——依赖管理

谁借莪１个温暖的怀抱￠ 2022-03-15 16:37 347阅读 0赞

一般在Maven项目中会引用很多依赖jar包，本文主要讲解Maven中关于依赖的内容。如有理解偏颇之处，欢迎各位大神指正。

# 依赖范围 #

*  compile：编译依赖范围。如果没有指定，默认会使用该依赖范围。使用此依赖范围，在编译，测试，运行时候都有效，都会使用该依赖
 *  test：测试依赖范围。只在测试有效，在编译主代码或运行项目的时候无法使用此类依赖，典型Junit，它只在编译测试代码或运行测试代码才有效
 *  provided：已提供依赖范围。在编译和测试时候有效，在运行的时候无效。例如servlet-api，编译和测试项目的时候需要该依赖，但是运行时因为容器已经提供，就不需要重复引入。
 *  runntime：运行时依赖范围。在测试和运行有效，但是在编译主代码的时候无效。例如JDBC驱动实现
 *  system：系统依赖范围。与provided依赖范围一致，但是使用该依赖，必须通过systemPath显式指定依赖文件的路径。此类路径不能痛殴Maven仓库解析，而且通常和本机系统绑定，移植性比较弱，慎重使用。
 *  import：导入依赖范围。不会对三种classpath产生实际影响。

# 传递依赖 #

何为传递依赖？

例如 A引用了B，C引用了B，那么在C中可以使用A的内容。那么A就是C的传递性依赖。Maven会解析各个直接依赖的POM，将必要的间接依赖，以传递性依赖的形式引入了当前项目中。

左侧第一列为第一直接依赖范围，最上面一列表示第二直接依赖范围，中间的交叉单元格为传递性依赖范围。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWRhamluZzI2Nw_size_16_color_FFFFFF_t_70][]

# **依赖调解  ** #

Maven引入的传递依赖机制，一方面可以简化依赖声明，一方面我们只需要关心项目直接依赖是什么。但是当传递依赖造成问题的时候就需要清楚知道依赖是从哪条依赖路径引入的。

例如项目A有这样的依赖关系：A->B->C->X(1.0), A->D->X(2.0),由于传递依赖，关于两个版本的X的究竟该使用哪一个呢？因此Maven在依赖调解的时候如下原则：路径最短优先，如果存在路径相同的时候采用第一声明者优先。即两个原则如下

**路径最短优先**

**第一声明者优先**

# 可选依赖 #

A->B、B->X(可选), B->Y(可选)，如果三者的依赖范围都为compile，因为X，Y是可选依赖，两者都不会得以传递，即**可选依赖不会对A产生任何影响**。出现这种情况一般是因为B同时实现了两个特性，而且两个特性，每个特性都分别依赖X，Y中的一种，而且相互排斥，例如支持多种数据库，但是真正使用的时候只能依赖一种数据库。

在使用坐标中时候使用元素<optional>元素true的时候表示为可选依赖，如果想要在A中使用X，Y中的一种，需要显式声明需要使用的依赖。

说明：关于可选依赖，我们一般不推荐使用，本着设计模式中单一原则，一个项目功能应该是单一的，理论上不应该同时出现两个互斥的特性。

# 总结 #

本文主要讲解关于传递依赖的一些基础知识，在实际的使用过程，还可能遇到一些其他问题，之后会讲解一些在实际工作如何避免maven产生的坑。

随着知识理解深入的时候，越加的发现技术这条路需要脚踏实地，来不得一点虚假。当欲望太多，无法满足的时候，那就静下心来，一点点做吧，该有的都会回馈给我们的。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWRhamluZzI2Nw_size_16_color_FFFFFF_t_70]: /images/20220315/a41c3f3a6afb492cb0b609fd1313f007.png