本文出处:http://blog.csdn.net/alpslzy/article/details/40147885
一,继承
1,被继承项目与继承项目是父子目录关系
projectB在projectA目录下,则projectB应该如下设置:
2,被继承项目与继承项目是不是父子目录关系
不是父子目录时,子项目的pom.xml文件定义中的parent元素下再加上一个relativePath元素的定义,用以描述父项目的pom.xml文件相对于子项目的pom.xml文件的位置。
例如projectA,projectB平级时,projectB要继承projectA项目,则如下:
二,聚合
被聚合项目即父项目或者超级项目。
聚合的好处,在超级项目上进行mvn compile,则会把那些子模块项目都进行编译,免去一个个执行的麻烦。具体做法:
Ø 修改被聚合项目的pom.xml中的packaging元素的值为pom
Ø 在被聚合项目的pom.xml中的modules元素下指定它的子模块项目
1,被聚合项目和子模块项目在目录结构上是父子关系
目录结构如下所示:
------projectA
------projectB
-----pom.xml
------pom.xml
这个时候projectA的pom.xml应该这样定义:
2,被聚合项目和子模块项目在目录结构上是不是父子关系
具体做法是在module元素中指定以相对路径的方式指定子模块。例如平级时,被聚合项目应该如下设置:
三,依赖
使用方法
在dependency元素中我们主要通过依赖项目的groupId、artifactId和version来定义所依赖的项目。此外,还可以指定以下元素:
Ø type:对应于依赖项目的packaging类型,默认是jar
Ø scope:表示依赖项目的一个作用范围。scope的主要取值范围如下(还有一个是在Maven2.0.9以后版本才支持的import,关于import作用域将在后文《Dependency介绍》中做介绍):
- compile:这是它的默认值,这种类型很容易让人产生误解,以为只有在编译的时候才是需要的,其实这种类型表示所有的情况都是有用的,包括编译和运行时。而且这种类型的依赖性是可以传递的。
- provided:这个跟compile很类似,但是它表示你期望这个依赖项目在运行时由JDK或者容器来提供。这种类型表示该依赖只有在测试和编译的情况下才有效,在运行时将由JDK或者容器提供。这种类型的依赖性是不可传递的。
- runtime:这种类型表示该依赖在编译的时候不是必须的,只有在运行的时候才是必须的。
- test:这表示这种依赖只有测试的时候才需要,正常情况下是不需要的。
- import:关于import的介绍,可以看后文中对引入依赖项的介绍。
- system:这种类型跟provided类似,唯一不同的就是这种类型的依赖我们要自己提供jar包,这需要与另一个元素systemPath来结合使用。systemPath将指向我们系统上的jar包的路径,而且必须是给定的绝对路径。如下:
Ø optional:当该项目本身作为其他项目的一个依赖时标记该依赖为可选项。假设现在projectA有一个依赖性projectB,我们把projectB这个依赖项设为optional,这表示projectB在projectA的运行时不一定会用到。这个时候如果我们有另一个项目projectC,它依赖于projectA,那么这个时候因为projectB对于projectA是可选的,所以Maven在建立projectC的时候就不会安装projectB,这个时候如果projectC确实需要使用到projectB,那么它就可以定义自己对projectB的依赖。当一个依赖是可选的时候,我们把optional元素的值设为true,否则就不设置optional元素。
Ø exclusions:考虑这样一种情况,我们的projectA依赖于projectB,然后projectB又依赖于projectC,但是在projectA里面我们不需要projectB依赖的projectC,那么这个时候我们就可以在依赖projectB的时候使用exclusions元素下面的exclusion排除projectC。这个时候我们可以这样定义projectA对projectB的依赖:
依赖的传递性
假设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。
可选的依赖项
可选的依赖项表示可有可无,不一定需要的,它只是做一个标记。为了便于大家理解,我们先看这样一种情况,假设项目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项排除。
dependencyManagement介绍
dependencyManagement主要有两个作用,一个是集中管理项目的依赖项,另一个就是控制使用的依赖项的版本。1,集中管理依赖项
projectA中依赖groupC:artifactC:1.0,groupD:artifactD:1.0, projectB中依赖groupC:artifactC:1.0,groupE:artifactE:1.0。它们都依赖了artifactC,这样我们就可以创建一个新的项目,使用其dependencyManagement来统一管理这些依赖项。我们创建项目P来管理这些依赖项:
projectA: 从上面的定义我们可以看出,我们已经简化了projectA和projectB依赖项的定义,我们可以只在projectA和projectB中申明需要使用的依赖项, 而不必指定其对应的版本和作用范围等信息 ,当指定了这些信息时子项目中的定义会覆盖父项目的dependencyManagement中的定义,否则将使用dependencyManagement中的定义。这样也可以很方便我们对依赖项的版本进行统一管理。
2,控制依赖项使用的版本
看下面这样一种情况projectA
ProjectB 这样,当我们对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中申明的依赖项将比间接的依赖项具有更高的优先级。
3,引入依赖项
我们知道通过继承一个项目我们可以在子项目中很好的申明需要使用的父项目的dependencyManagement定义的依赖项。但是因为每个项目都只能申明唯一的一个父项目,这在某些时候就会限制我们的项目建立。为此Maven为我们提供了一种方法,那就是通过设定依赖项的scope为import。注意这种方式只有在Maven2.0.9以上的版本才能使用。
上面这个项目是用来统一管理项目的依赖项的。那么按照之前的那种继承机制,这个时候我们的项目artifactB是如下这样定义的:那么如果按照import这种形式的话,artifactB可以如下定义: