《Maven官方文档》-Maven依赖机制简介（一）

依赖机制是maven最为用户熟知的特性之一，同时也是maven所擅长的领域之一。单个项目的依赖管理并不难，

但是当你面对包含数百个模块的多模块项目和应用时，maven能帮你保证项目的高度控制力和稳定性。

大纲：

 传递性依赖

排除、可选依赖

依赖范围

依赖管理

导入依赖

系统依赖

传递性依赖是maven2.0的新特性。假设你的项目依赖于一个库，而这个库又依赖于其他库。你不必自己去找出所有这些依赖，你只需要加上你直接依赖的库，maven会隐式的把这些库间接依赖的库也加入到你的项目中。这个特性是靠解析从远程仓库中获取的依赖库的项目文件实现的。一般的，这些项目的所有依赖都会加入到项目中，或者从父项目继承，或者通过传递性依赖。

传递性依赖的嵌套深度没有任何限制，只是在出现循环依赖时会报错。

传递性依赖会导致包含库的依赖图增长的非常大。为了解决这个问题，maven也提供了额外的机制，能让你指定哪些依赖会被包含：

依赖调解 – 当项目中出现多个版本构件依赖的情形，依赖调解决定最终应该使用哪个版本。目前，maven 2.0只支持“短路径优先”原则，意思是项目会选择依赖关系树中路径最短的版本作为依赖。当然，你也可以在项目pom文件中显式指定使用哪个版本。值得注意的是，在maven2.0.8及之前的版本中，当两个版本的依赖路径长度一致时，哪个依赖会被使用是不确定的。不过从maven 2.0.9开始，pom中依赖声明的顺序决定了哪个版本会被使用，也叫作”第一声明原则”。

“短路径优先”意味着项目依赖关系树中路径最短的版本会被使用。例如，假设a、b、c之间的依赖关系是a->b->c->d(2.0)和a->e->(d1.0)，那么d(1.0)会被使用，因为a通过e到d的路径更短。但如果你想要强制使用d(2.0)，那你也可以在a中显式声明对d(2.0)的依赖。

依赖管理 – 在出现传递性依赖或者没有指定版本时，项目作者可以通过依赖管理直接指定模块版本。之前的章节说过，由于传递性依赖，尽管某个依赖没有被a直接指定，但也会被引入。相反的，a也可以将d加入<dependencymanagement>元素中，并在d可能被引用时决定d的版本号。

依赖范围 – 你可以指定只在当前编译范围内包含合适的依赖。 下面会介绍更多相关的细节。

排除依赖 – 如果项目x依赖于项目y，项目y又依赖项目z，项目x的所有者可以使用”exclusion”元素来显式排除项目z。

可选依赖 – 如果项目y依赖项目z，项目y的所有者可以使用”optional”元素来指定项目z作为x的可选依赖。那么当项目x依赖项目y时，x只依赖y并不依赖y的可选依赖z。项目x的所有者也可以根据自己的意愿显式指定x对z的依赖。（你可以把可选依赖理解为默认排除）。

依赖范围会影响传递性依赖，同时也会影响项目构建任务中使用的classpath。

maven有以下6种依赖范围：

compile

这是默认范围。如果没有指定，就会使用该依赖范围。编译依赖对项目所有的classpath都可用。此外，编译依赖会传递到依赖的项目。

provided

和compile范围很类似，但provided范围表明你希望由jdk或者某个容器提供运行时依赖。例如，当使用java ee构建一个web应用时，你会设置对servlet api和相关的java ee apis的依赖范围为provided，因为web容器提供了运行时的依赖。provided依赖只对编译和测试classpath有效，并且不能传递。

runtime

runtime范围表明编译时不需要依赖，而只在运行时依赖。此依赖范围对运行和测试classpath有效，对编译classpath无效。

test

test范围表明使用此依赖范围的依赖，只在编译测试代码和运行测试的时候需要，应用的正常运行不需要此类依赖。

system

系统范围与provided类似，不过你必须显式指定一个本地系统路径的jar，此类依赖应该一直有效，maven也不会去仓库中寻找它。

import（maven2.0.9及以上）

import范围只适用于pom文件中的<dependencymanagement>部分。表明指定的pom必须使用<dependencymanagement>部分的依赖。因为依赖已经被替换，所以使用import范围的依赖并不影响依赖传递。

每类依赖范围（除了import）通过不同方式影响传递性依赖，具体如下表所示。最左侧一列代表了直接依赖范围，最顶层一行代表了传递性依赖的范围，行与列的交叉单元格就表示最终的传递性依赖范围。表中的“-“表示该传递性依赖将会被忽略。

compile(*)

–

(*)注意：这里本来应该是compile范围，那样的话compile范围都必须显式指定-然而，有这样一种情况，你依赖的、继承自其它库中的类的库必须在编译时可用。考虑到这个原因，即使在依赖性传递情况下，编译时依赖仍然是compile范围。

maven提供了一个机制来集中管理依赖信息，叫做依赖管理元素”<dependencymanagement>”。假设你有许多项目继承自同一个公有的父项目，那可以把所有依赖信息放在一个公共的pom文件，并且在子pom中简单第引用该构件即可。通过一些例子可以更好的解释这个机制。下面是两个继承自同一个父项目的pom：

项目a

<project> … <dependencies> <dependency> <groupid>group-a</groupid> <artifactid>artifact-a</artifactid> <version>1.0</version> <exclusions> <exclusion> <groupid>group-c</groupid> <artifactid>excluded-artifact</artifactid> </exclusion> </exclusions> </dependency> <artifactid>artifact-b</artifactid> <type>bar</type> <scope>runtime</scope> </dependencies> </project>

项目b

<type>war</type>

这两个pom都依赖于同一个模块，同时每个pom又各自依赖于一个无关的模块。父项目的pom详细信息如下所示：

<dependencymanagement> </dependencymanagement>

这样两个子项目的pom文件就简单多了。

<!– this is not a jar dependency, so we must specify type. –>

注意：在这两个pom文件的依赖中，我们必须指定<type/>元素。因为与依赖管理元素匹配的依赖引用最小信息集是{groupid, artifactid, type, classfier}。许多情况下，依赖指向的jar不需要指定classfier。因为默认type是jar，默认classfiler为空，所以我们可以把信息集设置为{groupid, artifactid}。

依赖管理元素第二个非常有用的功能是控制传递性依赖中构件的版本。例子如下

项目a：

<modelversion>4.0.0</modelversion> <groupid>maven</groupid> <artifactid>a</artifactid> <packaging>pom</packaging> <name>a</name> <groupid>test</groupid> <version>1.2</version> <artifactid>b</artifactid> <scope>compile</scope> <artifactid>c</artifactid> <artifactid>d</artifactid>

项目b：

<parent> </parent> <name>b</name>

当在maven中有项目依赖b时，不管它们的pom文件中指定的版本是什么，构件a，b，c和d的版本都是1.0。

a和c都被声明为这个项目的依赖，根据依赖调解，a和c的版本都是1.0.同时a和c的依赖范围都被显式指定为runtime。

b定义在b的父项目的<dependencymanagement>元素中，因为在依赖性传递中<dependencymanagement>优先于依赖调解，所以b的版本是1.0，b是编译依赖范围。

最后，d是定义在b的<dependencymanagement>元素中。

这个章节描述的特性只在maven2.0.9及之后的版本才有。这意味着更早版本的maven不会解析包含import元素的pom文件。因此在使用该特性前，你必须慎重考虑。如果你打算使用这个特性，我们建议你使用enforcer插件来强制使用maven2.0.9及以上版本。

前面的例子描述了怎么通过继承来指定管理的依赖。然而，这对于更大的项目通常会更复杂，因为一个项目只能继承自一个父项目。为了解决这个问题，项目可以导入其他项目的管理依赖，这可以通过声明依赖一个包含值为”import”的<scope>元素的构件来实现。