依赖机制是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加入元素中，并在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文件中的部分。表明指定的POM必须使用部分的依赖。因为依赖已经被替换，所以使用import范围的依赖并不影响依赖传递。
每类依赖范围(除了import)通过不同方式影响传递性依赖，具体如下表所示。最左侧一列代表了直接依赖范围，最顶层一行代表了传递性依赖的范围，行与列的交叉单元格就表示最终的传递性依赖范围。表中的“-“表示该传递性依赖将会被忽略。
compile
provided
runtime
test
compile
compile(*)
-
runtime
-
provided
provided
-
provided
-
runtime
runtime
-
runtime
-
test
test
-
test
-
(*)注意：这里本来应该是compile范围，那样的话compile范围都必须显式指定-然而，有这样一种情况，你依赖的、继承自其它库中的类的库必须在编译时可用。考虑到这个原因，即使在依赖性传递情况下，编译时依赖仍然是compile范围。
依赖管理
Maven提供了一个机制来集中管理依赖信息，叫做依赖管理元素””。假设你有许多项目继承自同一个公有的父项目，那可以把所有依赖信息放在一个公共的POM文件，并且在子POM中简单第引用该构件即可。通过一些例子可以更好的解释这个机制。下面是两个继承自同一个父项目的POM：
项目A
…
group-a
artifact-a
1.0
group-c
excluded-artifact
group-a
artifact-b
1.0
bar
runtime
项目B
…
group-c
artifact-b
1.0
war
runtime
group-a
artifact-b
1.0
bar
runtime
这两个POM都依赖于同一个模块，同时每个POM又各自依赖于一个无关的模块。父项目的POM详细信息如下所示：
…
group-a
artifact-a
1.0
group-c
excluded-artifact
group-c
artifact-b
1.0
war
runtime
group-a
artifact-b
1.0
bar
runtime
这样两个子项目的POM文件就简单多了。
…
group-a
artifact-a
group-a
artifact-b
bar
…
group-c
artifact-b
war
group-a
artifact-b
bar
注意：在这两个POM文件的依赖中，我们必须指定元素。因为与依赖管理元素匹配的依赖引用最小信息集是{groupId, artifactId, type, classfier}。许多情况下，依赖指向的jar不需要指定classfier。因为默认type是jar，默认classfiler为空，所以我们可以把信息集设置为{groupId, artifactId}。
依赖管理元素第二个非常有用的功能是控制传递性依赖中构件的版本。例子如下
项目A：
4.0.0
maven
A
pom
A
1.0
test
a
1.2
test
b
1.0
compile
test
c
1.0
compile
test
d
1.2
项目B：
A
maven
1.0
4.0.0
maven
B
pom
B
1.0
test
d
1.0
test
a
1.0
runtime
test
c
runtime
当在maven中有项目依赖B时，不管它们的pom文件中指定的版本是什么，构件a，b，c和d的版本都是1.0。
a和c都被声明为这个项目的依赖，根据依赖调解，a和c的版本都是1.0.同时a和c的依赖范围都被显式指定为runtime。
b定义在B的父项目的元素中，因为在依赖性传递中优先于依赖调解，所以b的版本是1.0，b是编译依赖范围。
最后，d是定义在B的元素中。
依赖管理的标签详细描述信息可以从这里获取项目描述符引用
导入依赖
这个章节描述的特性只在Maven2.0.9及之后的版本才有。这意味着更早版本的Maven不会解析包含import元素的pom文件。因此在使用该特性前，你必须慎重考虑。如果你打算使用这个特性，我们建议你使用enforcer插件来强制使用Maven2.0.9及以上版本。
前面的例子描述了怎么通过继承来指定管理的依赖。然而，这对于更大的项目通常会更复杂，因为一个项目只能继承自一个父项目。为了解决这个问题，项目可以导入其他项目的管理依赖，这可以通过声明依赖一个包含值为”import”的元素的构件来实现。
项目B：
4.0.0
maven
B
pom
B
1.0
maven
A
1.0
pom
import
test
d
1.0
test
a
1.0
runtime
test
c
runtime
假设A就是上一个例子中定义的POM，那么最终的结果也是一致的。除了在B中定义的d模块，所有A的管理依赖都会导入到B中。
项目X：
4.0.0
maven
X
pom
X
1.0
test
a
1.1
test
b
1.0
compile
项目Y：
4.0.0
maven
Y
pom
Y
1.0
test
a
1.2
test
c
1.0
compile
项目Z：
4.0.0
maven
Z
pom
Z
1.0
maven
X
1.0
pom
import
maven
Y
1.0
pom
import
在上面的例子中，Z导入了X和Y的管理依赖。不过有个问题，X和Y都包含了依赖a。在这里，会使用1.1版本的a，因为X先被声明，并且a没有在Z的依赖管理中声明。
这个过程是递归进行的。假如X导入了另外的POM，Q，那么当解析Z的时候，所有Q的管理依赖看上去就都像在X中定义的一样。
当定义一个用于构建多项目的包含一些相关构件的依赖“库”时，导入依赖就十分有效。从“库”中引用一个或多个构件到项目中，是一种很常见的做法。然而，
保持项目中使用的依赖版本与库中发布的版本一致会有点麻烦。下面的模式描述了怎么生成一个供其它项目使用的“物料清单”(BOM)。
项目的根元素是BOM pom文件。它定义了库中创建的所有构件版本。其它要使用该库的项目必须将该pom导入到其pom文件中的元素中。
4.0.0
com.test
bom
1.0.0
pom
1.0.0
1.0.0
com.test
project1
${project1Version}
com.test
project2
${project1Version}
parent
parent子项目将BOM pom作为它的父项目。这是一个简单的多项目pom。
4.0.0
com.test
bom
1.0.0
pom
1.0.0
1.0.0
com.test
project1
${project1Version}
com.test
project2
${project1Version}
parent
接下来是真正的pom文件。
4.0.0
com.test
1.0.0
parent
com.test
project1
${project1Version}
jar
log4j
log4j
4.0.0
com.test
1.0.0
parent
com.test
project2
${project2Version}
jar
commons-logging
commons-logging
下面的例子说明了怎么在项目中使用“库”，而不必指定依赖模块的版本。
4.0.0
com.test
use
1.0.0
jar
com.test
bom
1.0.0
pom
import
com.test
project1
com.test
project2
最后，当创建引入依赖的项目时，需要注意以下几点：
不要尝试引入在当前pom中定义的子模块pom。那会导致不能定位pom和编译失败。
绝不要声明导入其他pom作为目标pom的父项目(或者祖父项目等)的pom文件。这会导致循环解析，并触发异常。
当引用有传递性依赖的模块时，需要指定依赖模块的版本。不这样做，这些模块可能没有确定的版本，从而导致编译失败。(这在任何情况下都应该是一个最佳实践，因为它保证了模块版本的不变性)
系统依赖
系统范围的依赖应该是一直可用，并且Maven不会去仓库中查找。系统范围依赖通常是指JDK或者VM提供的依赖。所以，系统依赖适用于这种情况：以前可以单独获取，但现在是由JDK提供的依赖。典型的例子就是JDBC标准扩展或者Java认证和授权服务(JAAS)。一个简单的例子如下：
…
javax.sql
jdbc-stdext
2.0
system
${java.home}/lib/rt.jar
…
如果你的构件依赖于JDK的tools.jar，那么系统路径的值如下所示：
…
sun.jdk
tools
1.5.0
system
${java.home}/../lib/tools.jar
…
扫一扫
616
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
