Maven知识点整理
依赖归类
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
<dependencies> <dependency>
<groupId>org.spring.framework< /groupId >
<artifactId>spring-core< /artifactId >
<version>${spring.version}< /version >
< /dependency >
<dependency>
<groupId>org.spring.framework< /groupId >
<artifactId>spring-beans< /artifactId >
<version>${spring.version}< /version >
< /dependency >
<dependency>
<groupId>org.spring.framework< /groupId >
<artifactId>spring-web< /artifactId >
<version>${spring.version}< /version >
< /dependency >
<dependency>
<groupId>org.spring.framework< /groupId >
<artifactId>spring-mock< /artifactId >
<version>${spring.version}< /version >
< /dependency >
< /dependencies >
<properties> <spring.version>2.5< /spring .version>
< /properties >
|
多模块 & 继承
在Maven的多模块工程中,都存在一个pom类型的工程作为根模块,该工程只包含一个pom.xml文件,在该文件中以模块(module)的形式声明它所包含的子模块,即多模块工程。
在子模块的pom.xml文件中,又以parent的形式声明其所属的父模块,即继承。
多模块的好处是你只需在根模块中执行Maven命令,Maven会分别在各个子模块中执行该命令,执行顺序通过Maven的Reactor机制决定。
1)如果保留webapp和core中对maven-multi-module的父关系声明,即保留 “<parent>... </parent>”,而删除maven-multi-module中的子模块声明,即“<modules>...<modules>”,会发生什么情况?此时,整个工程已经不是一个多模块工程,而只是具有父子关系的多个工程集合。如果我们在maven-multi-module目录下执行“mvn clean install”,Maven只会在maven-multi-module本身上执行该命令,继而只会将maven-multi-module安装到本地Repository中,而不会在webapp和core模块上执行该命令,因为Maven根本就不知道这两个子模块的存在。另外,如果我们在webapp目录下执行相同的命令,由于由子到父的关系还存在,Maven会在本地的Repository中找到maven-multi-module的pom.xml文件和对core的依赖(当然前提是他们存在于本地的Repository中),然后顺利执行该命令。
(2)如果保留maven-multi-module中的子模块声明,而删除webapp和core中对maven-multi-module的父关系声明,又会出现什么情况呢?此时整个工程只是一个多模块工程,而没有父子关系。Maven会正确处理模块之间的依赖关系,即在webapp模块上执行Maven命令之前,会先在core模块上执行该命令,但是由于core和webapp模块不再继承自maven-multi-module,对于每一个依赖,他们都需要自己声明,比如我们需要分别在webapp和core的pom.xml文件中声明对Junit依赖。
依赖范围(scope)
引入依赖范围的原因示例:
1 例如Junit,将Junit的jar包打包到发布包是没有必要的。
2 例如servlet-api,为了编译通过,我们引入servlet-api jar包;但因为web容器也会提供servlet-api,如果将servlet-api打包至WAR包,就会造成依赖冲突。
示例:
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<dependency> <groupId>junit< /groupId >
<artifactId>junit< /artifactId >
<version>4.4< /version >
<scope> test < /test >
< /dependency >
<dependency> <groupId>javax.servlet< /groupId >
<artifactId>servlet-api< /artifactId >
<version>3.1< /version >
<scope>provided< /scope >
< /dependency >
|
scope详解:
1 complie
默认值。参与当前项目的编译,后续的测试,运行,是一个比较强的依赖。
2 test
参与包括测试代码的编译,执行。比较典型的如junit。
3 runtime
被依赖项目无需参与项目的编译,不过后期的测试和运行周期需要其参与。
与compile相比,跳过编译而已.
oracle jdbc驱动架包就是一个很好的例子,一般scope为runntime。另外runntime的依赖通常和optional搭配使用,optional为true。我可以用A实现,也可以用B实现。
4 provided
打包的时候不包进去,别的设施(如Web Container)会提供。
事实上该依赖理论上可以参与编译,测试,运行等周期。
相当于compile,但是在打包阶段做了exclude的动作。
5 system
从参与度来说,也provided相同,不过被依赖项不会从maven仓库抓,而是从本地文件系统拿,一定需要配合systemPath属性使用。
依赖范围(scope) | 主源码classpath可用 | 测试源码classpath可用 | 会被打包 |
compile 缺省值 | TRUE | TRUE | TRUE |
test | FALSE | TRUE | FALSE |
runtime | FALSE | TRUE | TRUE |
provided | TRUE(外界提供) | TRUE | FALSE |
scope的依赖传递
A–>B–>C。当前项目为A,A依赖于B,B依赖于C。知道B在A项目中的scope,那么怎么知道C在A中的scope呢?答案是:
当C是test或者provided时,C直接被丢弃,A不依赖C;
否则A依赖C,C的scope继承于B的scope。
下面是一张nexus画的图。
分类器(classifer)
GAV是Maven坐标最基本最重要的组成部分,但GAV不是全部。
还有一个元素叫做分类器(classifier),90%的情况你不会用到它,但有些时候,分类器非常不可或缺。
举个简单的例子,当我们需要依赖TestNG的时候,简单的声明GAV会出错,因为TestNG强制需要你提供分类器,以区别jdk14和jdk15,我们需要这样声明对TestNG的依赖:
1
2
3
4
5
6
|
<dependency> <groupId>org.testng< /groupId >
<artifactId>testng< /artifactId >
<version>5.7< /version >
<classifier>jdk15< /classifier >
< /dependency >
|
你会注意到maven下载了一个名为testng-5.7-jdk15.jar的文件。
其命名模式实际上是<artifactId>-<version>-<classifier>.<packaging>。
理解了这个模式以后,你就会发现很多文件其实都是默认构件的分类器扩展,如 myapp-1.0-test.jar, myapp-1.0-sources.jar。
分类器还有一个非常有用的用途是:我们可以用它来声明对test构件的依赖,比如,我们在一个核心模块的src/test/java中声明了一些基础类,然后我们发现这些测试基础类对于很多其它模块的测试类都有用。没有分类器,我们是没有办法去依赖src/test/java中的内容的,因为这些内容不会被打包到主构件中,它们单独的被打包成一个模式为<artifactId>-<version>-test.jar的文件。
我们可以使用分类器来依赖这样的test构件:理解了分类器,那么可供依赖的资源就变得更加丰富。
1
2
3
4
5
6
|
<dependency> <groupId>org.myorg.myapp< /groupId >
<artifactId>core< /artifactId >
<version>${project.version}< /version >
<classifier> test < /classifier >
< /dependency >
|
依赖管理(dependencyManagement)
实际的项目中,你会有一大把的Maven模块,而且你往往发现这些模块有很多依赖是完全项目的,A模块有个对spring的依赖,B模块也有,它们的依赖配置一模一样,同样的groupId, artifactId, version,或者还有exclusions, classifer。
细心的分会发现这是一种重复,重复就意味着潜在的问题,Maven提供的dependencyManagement就是用来消除这种重复的。
正确的做法是:
1. 在父模块中使用dependencyManagement配置依赖
2. 在子模块中使用dependencies添加依赖
dependencyManagement实际上不会真正引入任何依赖,dependencies才会。但是,当父模块中配置了某个依赖之后,子模块只需使用简单groupId和artifactId就能自动继承相应的父模块依赖配置。
依赖配置越复杂,依赖管理所起到的作用就越大,它不仅能够帮助你简化配置,它还能够帮你巩固依赖配置,也就是说,在整个项目中,对于某个构件(如mysql)的依赖配置只有一种,这样就能避免引入不同版本的依赖,避免依赖冲突。
示例:
父模块:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
<project> <modelVersion>4.0.0< /modelVersion >
<groupId>org.sonatype.mavenbook< /groupId >
<artifactId>a-parent< /artifactId >
<version>1.0.0< /version >
...
<dependencyManagement>
<dependencies>
<dependency>
<groupId>mysql< /groupId >
<artifactId>mysql-connector-java< /artifactId >
<version>5.1.2< /version >
< /dependency >
...
<dependencies>
< /dependencyManagement >
|
子模块:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
<project> <modelVersion>4.0.0< /modelVersion >
<parent>
<groupId>org.sonatype.mavenbook< /groupId >
<artifactId>a-parent< /artifactId >
<version>1.0.0< /version >
< /parent >
<artifactId>project-a< /artifactId >
...
<dependencies>
<dependency>
<groupId>mysql< /groupId >
<artifactId>mysql-connector-java< /artifactId >
< /dependency >
< /dependencies >
< /project >
|
传递依赖 & 依赖冲突
依赖冲突时,Maven采用“最近获胜策略(nearest wins strategy)”。
如果一个项目最终依赖于相同artifact的多个版本,在依赖树中离项目最近的那个版本将被使用。
示例:
github源代码:https://github.com/davenkin/maven-dependency-conflict-demo
resolve-web项目的依赖关系如下:
根据Maven的transitive依赖机制,resolve-web将同时依赖于project-common的1.0和2.0版本,这就造成了依赖冲突。而根据最近获胜策略,Maven将选择project-common的1.0版本作为最终的依赖。
在resolve-web中执行"mvn dependency:tree -Dverbose"可以看到resolve-web的依赖关系:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
[INFO] resolve-web:resolve-web:war:1.0-SNAPSHOT [INFO] +- junit:junit:jar:3.8.1: test
[INFO] +- project-B:project-B:jar:1.0:compile [INFO] | \- project-C:project-C:jar:1.0:compile [INFO] | \- (project-common:project-commmon:jar:2.0:compile - omitted for conflict with 1.0)
[INFO] +- project-A:project-A:jar:1.0:compile [INFO] | \- project-common:project-commmon:jar:1.0:compile [INFO] \- javax.servlet:servlet-api:jar:2.4:provided |
由上可知,project-common:project-commmon:jar:2.0被忽略掉了。此时在resolve-web的war包中将只包含project-common的1.0版本,于是问题来了。由于project-common的1.0版本中不包含sayGoodBye()方法,而该方法正是project-C所需要的,所以运行时将出现“NoSuchMethodError”。
对于这种有依赖冲突所导致的问题,我们有两种解决方法。
方法1:显式加入对project-common 2.0版本的依赖。先前的2.0版本不是离resolve-web远了点吗,那我们就直接将它作为resolve-web的依赖,这不就比1.0版本离resolve-web还近吗?在resove-web的pom.xml文件中直接加上对project-common 2.0 的依赖:
1
2
3
4
5
|
<dependency> <groupId>project-common< /groupId >
<artifactId>project-commmon< /artifactId >
<version>2.0< /version >
< /dependency >
|
方法2:resolve-web对project-A的dependency声明中,将project-common排除掉。在resolve-web的pom.xml文件中修改对project-A的dependency声明:
1
2
3
4
5
6
7
8
9
10
11
|
<dependency> <groupId>project-A< /groupId >
<artifactId>project-A< /artifactId >
<version>1.0< /version >
<exclusions>
<exclusion>
<groupId>project-common< /groupId >
<artifactId>project-commmon< /artifactId >
< /exclusion >
< /exclusions >
< /dependency >
|
方法3:另外,我们还可以在project-A中将对project-common的依赖声明为optional,optional即表示非transitive,此时当在resolve-web中引用project-A时,Maven并不会将project-common作为transitive依赖自动加入,除非有别的项目(比如project-B)声明了对project-common的transitive依赖或者我们在resolve-web中显式声明对project-common的依赖(方法一)。
Profile
Maven的Profile用于在不同的环境下应用不同的配置。一套配置即称为一个Profile。
Maven提供了Activation机制来**某个Profile,它既允许自动**(即在某些条件满足时自动使某个Profile生效),也可以手动**。
Profile可配置“<activeByDefault>true</activeByDefault>”,表明该Profile默认即是生效的。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
|
<profiles> <profile>
< id >apple< /id >
<activation>
<activeByDefault> true < /activeByDefault >
< /activation >
<properties>
<fruit>APPLE< /fruit >
< /properties >
< /profile >
<profile>
< id >banana< /id >
<properties>
<fruit>BANANA< /fruit >
< /properties >
< /profile >
< /profiles >
|
为了打印出fruit这个属性,我们再向pom.xml中添加一个maven-antrun-plugin插件,我们可以通过该插件的echo任务来打印属性信息。我们将该打印配置在Maven的initialize阶段(任何阶段都可以):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
<plugin> <artifactId>maven-antrun-plugin< /artifactId >
<executions>
<execution>
<phase>initialize< /phase >
<goals>
<goal>run< /goal >
< /goals >
<configuration>
<tasks>
< echo >Fruit:${fruit}< /echo >
< /tasks >
< /configuration >
< /execution >
< /executions >
< /plugin >
|
配置完成之后,执行:“mvn initialize”,由于id为apple的Profile默认生效,此时将在终端输出“APPLE”字样:
1
2
3
4
5
6
7
8
9
|
...... [INFO] Executing tasks [ echo ] Fruit:APPLE
[INFO] Executed tasks ...... |
如果要使用id为banana的Profile,我们可以显式地指定使用该Profile:"mvn initialize -Pbanana"
私服(Repository)
Maven提高篇系列之(三)——使用自己的Repository(Nexus)
Plugin
Maven就其本身来说只是提供一个执行环境,它并不知道需要在项目上完成什么操作,真正操作项目的是插件(plugin)。
比如编译Java有Compiler插件,打包有Jar插件等。
所以要让Maven完成各种各样的任务,我们需要配置不同的插件,甚至自己编写插件。
参考资料: