Maven依赖详解

本篇目标：通过讲解maven依赖范围、传递性依赖、可选依赖、依赖调节，让大家知道maven依赖的正确使用姿势是什么。

什么是依赖范围

Java在进行代码编译和运行的时候都分别需要指定classpath路径，不然将会出现找不到对应的类。同样的maven默认提供了编译主代码时、测试代码时、运行时的3套classpath。而依赖范围就是用来控制该jar应该被引入哪一个classpath中，maven有以下几种依赖范围：

• compile

jar包会引入上述声明的3个classpt

• test

jar包会引入测试代码时的classpath

• provided

jar包会引入编译主代码时、测试代码时的classpth

• runtime

jar包会引入测试代码时和运行时的classpath

maven中未指定时默认的依赖范围为compile

什么是传递性依赖

指X->B , B->C ,那么X是否依赖了C呢？如果依赖了那么它的依赖范围又是什么呢？maven对于这几种情况都分别进行的规范定义，如图1-1:

最左边一列即为X工程第一直接依赖范围，最上一行为X工程第二直接依赖范围，其它的为X工程最终的传递性依赖范围。举个例子：X->B（依赖范围：compile） ， B->C（依赖范围：test） ,那么X对于C的传递性依赖范围由图1-1得 test。
由图1-1我们可以总结如下几点：

1. 如果第二直接依赖范围为compile，那么传递性依赖范围与第一直接依赖范围是一致的。
2. 如果第二直接依赖范围为test，那么依赖是不会进行传递的。
3. 如果第二直接依赖范围是provied,那么只有第一直接依赖范围是provided才会进行传递，其余不会。

什么是可选依赖

我们知道maven的依赖是可以进行传递的，但是对于有一些jar我们是不希望它进行传递的，可以通过**< optional >true< / optional>** 将它标记为可选依赖，那么该依赖将不会被进行传递。

依赖调节

当项目存在这种依赖情况时：X->B,C(1.0版本) , B->C(1.1版本)，maven会参照以下两条原则自动进行依赖调节：

1. 路径最短优先
2. 路径相同时，采取配置顺序优先

如上情况X工程最终依赖的是C(1.0版本)

我们可以通过现主流的idea来更直观的看看maven是如何进行依赖调节的,假设member-web工程的依赖关系如图1-2

根据路径最短优先member-web将会依赖member-dao1:1.0 ,idea的依赖解析插件将会如图1-3进行展示：

书写技术文章是一个循序渐进的过程，所以我不能保证每句话、每行代码都是对的，但至少能保证不复制、不粘贴，每篇文章都是自己对技术的认识、细心斟酌总结出来的。乔布斯说：我们在这个星球上的时间都很短，很少有机会去做几件真正伟大的事情，同时要做得好，我必须要趁我还年轻的时候完成这些事。
其实我想说的是，我是一枚程序员，我只想在有限的时间内尽可能去沉淀我这一生中所能沉淀下来的东西

---

清山绿水始于尘，博学多识贵于勤。

我有酒，你有故事吗？

微信公众号：「Java锦囊」。

欢迎一起谈天说地，聊Java。

---