00001-Maven简介—Dependency

Dependency介绍

1依赖的传递性

当项目A依赖于B，而B又依赖于C的时候，自然的A会依赖于C，这样Maven在建立项目A的时候，会自动加载对C的依赖。

依赖传递对版本的选择

假设A依赖于B和C，然后B依赖于D，D又依赖于E1.0，C直接依赖于E2.0，那么这个时候A依赖的是E1.0还是E2.0，还是这两个都依赖呢？两个都依赖是肯定不行的，因为它们可能会有冲突的地方。这个时候就涉及到Maven中依赖传递对版本的选择问题。依赖传递在选择版本的时候首先是根据深度选择的。当一个项目同时经过不同的路径依赖于同一个组件时，会选择其深度最短的对应组件进行依赖。举例来说，假设A->B->C->D1.0，A->E->D2.0，那么这个时候A就会选择对D相对路径短的组件来进行依赖，也就是D2.0。那么当深度一样的时候Maven会如何选择呢？即A->B->D1.0和A->C->D2.0，这个时候Maven会如何选择A所依赖的D的版本呢？这种情况Maven会根据申明的依赖顺序来进行选择，先申明的会被作为依赖包。向前面这种情况，如果先申明对B的依赖，则A依赖的就是D1.0，如果先申明对C的依赖，则A依赖的就是D2.0。

使用exclusion 排除依赖

假设有这样一种依赖关系，A->B->C，这个时候由于某些原因，我们不需要对C的依赖，但是我们又必须要对B的依赖，这个时候该怎么办呢？针对这种情况，Maven给我们提供了一个exclusion功能，我们可以在添加A对B的依赖时申明不需要引进B对C的依赖。具体做法如下：

<dependencies>  
       <dependency>  
              <groupId>groupB</groupId>  
              <artifactId>artifactB</artifactId>  
              <version>1.0</version>  
              <exclusions>  
                     <exclusion>  
                            <groupId>groupC</groupId>  
                            <artifactId>artifactC</artifactId>  
                     </exclusion>  
              </exclusions>  
       </dependency>  
       ...  
</dependencies>

可选的依赖项

可选的依赖项表示可有可无，不一定需要的，它只是做一个标记。为了便于大家理解，我们先看这样一种情况，假设项目B依赖于项目C，这个时候我们把B对C的依赖利用optional标记为可选的，它意味着B中只有部分地方用到了C，并不是必须要的，当你依赖于B，但是又不需要使用到B的C功能时，可以不依赖于C。这样当A->B->C时，在建立项目A的时候将不会加入对C的依赖，因为C对B是可选的，我们不一定会用到C。但是在建立项目B的时候，Maven就会加入对C的依赖。也就是说这种标记为optional的依赖项对项目本身而言是没有什么影响的，它影响的是以该项目作为依赖项的其他项目，如这里的项目A。这种可选的依赖项有一个好处就是它会默认的作为exclusion项排除。

<project>  
       <groupId>groupB</groupId>  
       <artifactId>artifactB</artifactId>  
       <version>1.0</version>  
       <dependencies>  
              <dependency>  
                     <groupId>groupC</groupId>  
                     <artifactId>artifactC</artifactId>  
                     <version>1.0</version>  
                     <optional>true</optional>  
              </dependency>  
              ...  
       </dependencies>  
</project>

<project>  
       <groupId>groupA</groupId>  
       <artifactId>artifactA</artifactId>  
       <version>1.0</version>  
       <dependencies>  
              <dependency>  
                     <groupId>groupB</groupId>  
                     <artifactId>artifactB</artifactId>  
                     <version>1.0</version>  
              </dependency>  
              ...  
       </dependencies>  
</project>

2 依赖项的作用域

在定义项目的依赖项的时候，我们可以通过scope来指定该依赖项的作用范围。scope的取值有compile、runtime、test、provided、system和import。

compile：这是依赖项的默认作用范围，即当没有指定依赖项的scope时默认使用compile。compile范围内的依赖项在所有情况下都是有效的，包括运行、测试和编译时。

runtime：表示该依赖项只有在运行时才是需要的，在编译的时候不需要。这种类型的依赖项将在运行和test的类路径下可以访问。

test：表示该依赖项只对测试时有用，包括测试代码的编译和运行，对于正常的项目运行是没有影响的。

provided：表示该依赖项将由JDK或者运行容器在运行时提供，也就是说由Maven提供的该依赖项我们只有在编译和测试时才会用到，而在运行时将由JDK或者运行容器提供。

system：当scope为system时，表示该依赖项是我们自己提供的，不需要Maven到仓库里面去找。指定scope为system需要与另一个属性元素systemPath一起使用，它表示该依赖项在当前系统的位置，使用的是绝对路径。比如官网给出了一个关于使用JDK的tools.jar的例子：

<project>  
  ...  
  <dependencies>  
    <dependency>  
      <groupId>sun.jdk</groupId>  
      <artifactId>tools</artifactId>  
      <version>1.5.0</version>  
      <scope>system</scope>  
      <systemPath>${java.home}/../lib/tools.jar</systemPath>  
    </dependency>  
  </dependencies>  
  ...  
</project>

import：关于import的介绍，可以看后文中对引入依赖项的介绍。

3 dependencyManagement介绍

dependencyManagement主要有两个作用，一个是集中管理项目的依赖项，另一个就是控制使用的依赖项的版本。

3.1集中管理依赖项

看这样一种情况，我们有以下两个项目：
projectA

<project>  
       <groupId>groupA</groupId>  
       <artifactId>artifactA</artifactId>  
       <version>1.0</version>  
       <dependencies>  
              <dependency>  
                     <groupId>groupC</groupId>  
                     <artifactId>artifactC</artifactId>  
                     <version>1.0</version>  
              </dependency>  
              <dependency>  
                     <groupId>groupD</groupId>  
                     <artifactId>artifactD</artifactId>  
                     <version>1.0</version>  
              </dependency>  
       </dependencies>  
       ...  
</project>

ProjectB

<project>  
       <groupId>groupB</groupId>  
       <artifactId>artifactB</artifactId>  
       <version>1.0</version>  
       <dependencies>  
              <dependency>  
                     <groupId>groupC</groupId>  
                     <artifactId>artifactC</artifactId>  
                     <version>1.0</version>  
              </dependency>  
              <dependency>  
                     <groupId>groupE</groupId>  
                     <artifactId>artifactE</artifactId>  
                     <version>1.0</version>  
                     <type>bar</type>  
              </dependency>  
       </dependencies>  
       ...  
</project>

从这两个项目中我们可以看出来，它们都依赖了artifactC，这样我们就可以创建一个新的项目，使用其dependencyManagement来统一管理这些依赖项。我们创建项目P来管理这些依赖项：

projectP

<project>  
       ...  
       <dependencyManagement>  
              <dependencies>  
                     <dependency>  
                            <groupId>groupC</groupId>  
                            <artifactId>artifactC</artifactId>  
                            <version>1.0</version>  
                     </dependency>  
                     <dependency>  
                            <groupId>groupD</groupId>  
                            <artifactId>artifactD</artifactId>  
                            <version>1.0</version>  
                     </dependency>  
                     <dependency>  
                            <groupId>groupE</groupId>  
                            <artifactId>artifactE</artifactId>  
                            <version>1.0</version>  
                            <type>bar</type>  
                     </dependency>  
              </dependencies>  
       </dependencyManagement>  
       ...  
</project>

之后我们就可以这样来定义我们的projectA和projectB。

projectA

<project>  
       <modelVersion>4.0</modelVersion>  
       <groupId>groupA</groupId>  
       <artifactId>artifactA</artifactId>  
       <version>1.0</version>  
       <dependencies>  
              <dependency>  
                     <groupId>groupC</groupId>  
                     <artifactId>artifactC</artifactId>  
              </dependency>  
              <dependency>  
                     <groupId>groupD</groupId>  
                     <artifactId>artifactD</artifactId>  
              </dependency>  
       </dependencies>  
       ...  
</project>

ProjectB

<project>  
       <modelVersion>4.0</modelVersion>  
       <groupId>groupB</groupId>  
       <artifactId>artifactB</artifactId>  
       <version>1.0</version>  
       <dependencies>  
              <dependency>  
                     <groupId>groupC</groupId>  
                     <artifactId>artifactC</artifactId>  
              </dependency>  
              <dependency>  
                     <groupId>groupE</groupId>  
                     <artifactId>artifactE</artifactId>  
              <!--因为artifactE的类型不是默认的jar，所以这里需要指定依赖项的类型-->  
                     <type>bar</type>  
              </dependency>  
       </dependencies>  
       ...  
</project>

从上面的定义我们可以看出，我们已经简化了projectA和projectB依赖项的定义，我们可以只在projectA和projectB中申明需要使用的依赖项，而不必指定其对应的版本和作用范围等信息，当指定了这些信息时子项目中的定义会覆盖父项目的dependencyManagement中的定义，否则将使用dependencyManagement中的定义。这样也可以很方便我们对依赖项的版本进行统一管理。

3.2控制依赖项使用的版本

看下面这样一种情况

projectA

<project>  
       <modelVersion>4.0</modelVersion>  
<groupId>groupA</groupId>  
       <artifactId>artifactA</artifactId>  
       <version>1.0</version>  
       <packaging>pom</packaging>  
       <dependencyManagement>  
              <dependencies>  
                     <dependency>  
                            <groupId>groupA</groupId>  
                            <artifactId>A</artifactId>  
                            <version>1.5</version>  
                     </dependency>  
                     <dependency>  
                            <groupId>groupA</groupId>  
                            <artifactId>B</artifactId>  
                            <version>1.0</version>  
                     </dependency>  
                     <dependency>  
                            <groupId>groupA</groupId>  
                            <artifactId>C</artifactId>  
                            <version>1.0</version>  
                     </dependency>  
                     <dependency>  
                            <groupId>groupA</groupId>  
                            <artifactId>D</artifactId>  
                            <version>1.6</version>  
                     </dependency>  
              </dependencies>  
       </dependencyManagement>  
       ...  
</project>

ProjectB

<project>  
       <modelVersion>4.0</modelVersion>  
       <groupId>groupB</groupId>  
       <artifactId>artifactB</artifactId>  
       <version>1.0</version>  
       <packaging>pom</packaging>  
       <dependencyManagement>  
              <dependencies>  
                     <dependency>  
                            <groupId>groupA</groupId>  
                            <artifactId>A</artifactId>  
                            <version>1.0</version>  
                     </dependency>  
              </dependencies>  
       </dependencyManagement>  
       <dependencies>  
              <dependency>  
                     <groupId>groupA</groupId>  
                     <artifactId>B</artifactId>  
                     <version>1.8</version>  
              </dependency>  
              <dependency>  
                     <groupId>groupA</groupId>  
                     <artifactId>C</artifactId>  
                     <scope>runtime</scope>  
              </dependency>  
       </dependencies>  
       ...  
</project>

这样，当我们对projectB进行Maven操作的时候，依赖项A、B、C和D将会如下选择：
当A是B或者C的一个依赖项的时候，projectB将使用的是A的1.0版本，因为A是申明在projectB的dependencyManagement中的，此外申明在dependencyManagement中的依赖项将比项目的依赖项的依赖项有更高的优先级，还有就是当前项目的申明将比其父项目的申明具有更高的优先级。

依赖项B将使用版本1.8，因为依赖项B是直接申明在projectB中的，而且指定了版本为1.8，所以当前项目申明的版本会覆盖父项目的dependencyManagement中指定的版本。

依赖项C将使用版本1.0，但是其作用范围将会是runtime。因为依赖项C也是直接申明在projectB中的，而且其没有指定自己所使用的版本，所以将使用其父项目的dependencyManagement中指定的版本。此外，其指定了自己所作用的范围是runtime，所以它会覆盖其父项目的dependencyManagement中所指定依赖项的默认的compile作用范围。

依赖项D将使用版本1.6。当D是B或者C的一个依赖项的时候，projectB将使用D的1.6版本，因为项目D是申明在dependencyManagement中的，而且在dependencyManagement中申明的依赖项将比间接的依赖项具有更高的优先级。

4 引入依赖项

我们知道通过继承一个项目我们可以在子项目中很好的申明需要使用的父项目的dependencyManagement定义的依赖项。但是因为每个项目都只能申明唯一的一个父项目，这在某些时候就会限制我们的项目建立。为此Maven为我们提供了一种方法，那就是通过设定依赖项的scope为import。注意这种方式只有在Maven2.0.9以上的版本才能使用。

<project>  
       ...  
       <groupId>groupA</groupId>  
       <artifactId>artifactA</artifactId>  
       <version>1.0</version>  
       <packaging>pom</packaging>  
       <dependencyManagement>  
              <dependencies>  
                     <dependency>  
                            <groupId>test</groupId>  
                            <artifactId>A</artifactId>  
                            <version>1.0</version>  
                     </dependency>  
                     <dependency>  
                            <groupId>test</groupId>  
                            <artifactId>B</artifactId>  
                            <version>1.1</version>  
                     </dependency>  
                     <dependency>  
                            <groupId>test</groupId>  
                            <artifactId>C</artifactId>  
                            <version>1.2</version>  
                     </dependency>  
                     <dependency>  
                            <groupId>test</groupId>  
                            <artifactId>D</artifactId>  
                            <version>1.3</version>  
                     </dependency>  
              </dependencies>  
       </dependencyManagement>  
       ...  
</project>

上面这个项目是用来统一管理项目的依赖项的。那么按照之前的那种继承机制，这个时候我们的项目artifactB是如下这样定义的：

<project>  
       ...  
       <parent>  
              <groupId>groupA</groupId>  
              <artifactId>artifactA</artifactId>  
              <version>1.0</version>  
       </parent>  
       <groupId>groupA</groupId>  
       <artifactId>artifactB</artifactId>  
       <version>1.0</version>  
       <packaging>pom</packaging>  
       <dependencies>  
              <dependency>  
                     <groupId>test</groupId>  
                     <artifactId>A</artifactId>  
              </dependency>  
              <dependency>  
                     <groupId>test</groupId>  
                     <artifactId>D</artifactId>  
                     <scope>runtime</scope>  
              </dependency>  
       </dependencies>  
       ...  
</project>

那么如果按照import这种形式的话，artifactB可以如下定义：

<project>  
       ...  
       <groupId>groupA</groupId>  
       <artifactId>artifactB</artifactId>  
       <version>1.0</version>  
       <packaging>pom</packaging>  
       <dependencyManagement>  
              <dependencies>  
                     <dependency>  
                            <groupId>groupA</groupId>  
                            <artifactId>artifactA</artifactId>  
                            <version>1.0</version>  
                            <type>pom</type>  
                            <scope>import</scope>  
                     </dependency>  
              </dependencies>  
       </dependencyManagement>  
       <dependencies>  
              <dependency>  
                     <groupId>test</groupId>  
                     <artifactId>A</artifactId>  
              </dependency>  
              <dependency>  
                     <groupId>test</groupId>  
                     <artifactId>D</artifactId>  
                     <scope>runtime</scope>  
              </dependency>  
       </dependencies>  
       ...  
   
</project>

参考文章：
参考一

人面猴
序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
沈念sama阅读 206,482评论 6赞 481
死咒
序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
沈念sama阅读 88,377评论 2赞 382
救了他两次的神仙让他今天三更去死
文/潘晓璐我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
开封第一讲书人阅读 152,762评论 0赞 342
道士缉凶录：失踪的卖姜人
文/不坏的土叔我叫张陵，是天一观的道长。经常有香客问我，道长，这世上最难降的妖魔是什么？我笑而不...
开封第一讲书人阅读 55,273评论 1赞 279
港岛之恋（遗憾婚礼）
正文为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
茶点故事阅读 64,289评论 5赞 373
恶毒庶女顶嫁案：这布局不是一般人想出来的
文/花漫我一把揭开白布。她就那样静静地躺着，像睡着了一般。火红的嫁衣衬着肌肤如雪。梳的纹丝不乱的头发上，一...
开封第一讲书人阅读 49,046评论 1赞 285
城市分裂传说
那天，我揣着相机与录音，去河边找鬼。笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。我是一名探鬼主播，决...
沈念sama阅读 38,351评论 3赞 400
双鸳鸯连环套：你想象不到人心有多黑
文/苍兰香墨我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
开封第一讲书人阅读 36,988评论 0赞 259
万荣杀人案实录
序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
沈念sama阅读 43,476评论 1赞 300
护林员之死
正文独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋以下内容为张勋视角年9月15日...
茶点故事阅读 35,948评论 2赞 324
白月光启示录
正文我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
茶点故事阅读 38,064评论 1赞 333
活死人
序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
沈念sama阅读 33,712评论 4赞 323
日本核电站爆炸内幕
正文年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
茶点故事阅读 39,261评论 3赞 307
男人毒药：我在死后第九天来索命
文/蒙蒙一、第九天我趴在偏房一处隐蔽的房顶上张望。院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
开封第一讲书人阅读 30,264评论 0赞 19
一桩弑父案，背后竟有这般阴谋
文/苍兰香墨我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。一阵脚步声响...
开封第一讲书人阅读 31,486评论 1赞 262
情欲美人皮
我被黑心中介骗来泰国打工，没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。一个月前我还...
沈念sama阅读 45,511评论 2赞 354
代替公主和亲
正文我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
茶点故事阅读 42,802评论 2赞 345

00001-Maven简介—Dependency

Dependency介绍

1依赖的传递性

可选的依赖项

2 依赖项的作用域

3 dependencyManagement介绍

3.1集中管理依赖项

3.2控制依赖项使用的版本

4 引入依赖项

推荐阅读更多精彩内容