7 Dependency介绍
7.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>
7.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的介绍，可以看后文中对引入依赖项的介绍。
7.3 dependencyManagement介绍
dependencyManagement主要有两个作用，一个是集中管理项目的依赖项，另一个就是控制使用的依赖项的版本。
7.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中的定义。这样也可以很方便我们对依赖项的版本进行统一管理。
7.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中申明的依赖项将比间接的依赖项具有更高的优先级。
7.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>
相关推荐
New——project——maven——找到webapp结尾——next 一、导入tomacat 1.找到文件下的tomcat 2.Deployment添加创建的项目（artifact） 3.应用 二、讲述mvc功能、jsp、servelet控制层如何实现、作用等 三、下载并解压...
mvn org.apache.maven.plugins:maven-dependency-plugin:2.6:purge-local-repository -DmanualInclude=branchitech.maven:branchitech-tools 运行以下指令以准备导入导出工具 mvn branchitech:branchitech-dbtools...
1. 优先按照依赖管理 [dependencyManagement] 元素中指定的版本进行仲裁 2. 若无版本声明，则按照 “短路径优先” 原则（Maven2.
缓存——LRU Java 缓存描述快速 ... 查看Maven 依赖 < dependency> < groupId>com.github.barakb</ groupId> < artifactId>concurrent-cache</ artifactId> < version>1.0</ version> </ dependency>
对于具有通用“每个用户请求的线程”架构的服务器来说，这可能会导致灾难——如果某些服务变得没有响应，那么在高负载下，所有服务器的线程都可能处于该服务的等待集中，整个系统变得没有React。 为避免此类情况而...
适用于 Android 的幻灯片布局演示版设置Maven： < dependency> < groupId>com.dsiner.lib</ groupId> < artifactId>slidelayout</ artifactId> < version>1.0.4</ version></ dependency> 或Gradle： compile ' ...
< dependency> < groupId>hummingcat</ groupId> < artifactId>hummingcat</ artifactId> < version>0.1.1</ version></ dependency>用法首先，要求项目： ( use 'hiccup.core) # Hiccup is for html generation( ...
MAVEN地址 2.1.0版本是未集成Mybatis-plus版本——源码分支master <dependency> <groupId>com.github.flying-cattle</groupId> <artifactId>mybatis-dsc-generator <version>2.1.0.RELEASE </dependency> 3.0.0后的...
精灵一个 Clojure 库，旨在帮助记录和...入门Elv 工件 [部署到 clojars] ( ) 与莱宁根： [elv "0.1.0"]使用 Gradle：编译“elv:elv:0.1.0” 使用 Maven： <dependency> <groupId>elv</groupId> <artifactId>elv</art
解耦 在jxl包基础上做了小扩展，程序员只要专注塞数据——把数据塞到我们提供的bean。之后bean转excel，由这个组件搞定。该组件已经优化了表格样式，可以省却调试excel样式的痛苦 灵活排序 可以很方便地调整每列的...
Maven 中： < dependency > < groupId > com.github.aro-tech </ groupId > < artifactId > interface-it </ artifactId > < version > 1.1.3 </ version > </ dependency > ##Background ...
疯狂的附魔 疯狂附魔的源代码 生成状态： 最新版本： 詹金斯： 关系： Maven： < id>nexus < url>https://nexus.badbones69.com/repository/maven-releases/</ url> ...< dependency> ...</ dependency>
或应用程序容器——尽管它与这些集成得很好。 您的应用程序数据通过一个简单的、单一方法的 Java 接口提供给 Zabbix/J。 当您启动应用程序时，您只需实例化、配置和启动 Zabbix/J 单例 — 如果您使用的是 Spring ...
然后，这些程序可以毫不费力地转移到新环境和新数据源或目的地——最好是通过配置。 主要特征 使用相同代码支持批处理和流处理的统一 API 避免供应商锁定 - 在不同引擎之间迁移是配置问题 使用 Java 8 Lambda 表达式...