一 坐标详解
1.1 坐标的作用
1.2 坐标元素详解
<groupId>org.sonatype.nexus</groupId>
<artifactId>nexus-indexer</artifactId>
<version>2.0.0</version>
<packaging>jar</packaging>
version:该元素定义了Maven项目当前所处的版本。实际上,Maven定义了一套完整的版本规范,以及快照(SNAPSHOT)的概念。在后面的章节将详细讨论。
packaging:该元素定义Maven项目的打包方式。首先,打包方式通常与所生成构件的文件扩展名对应,如上例中packaging为jar,最终的文件名为nexus-indexer-2.0.0.jar。而是用war打包方式的Maven项目,最终生成的构件会有一个.war文件,但这不是绝对的。当不定义packaging时,Maven会是用默认值jar。
classifier:该元素用来帮助定义构件输出的一些附属构件。附属构件与主构件对应。如上例中的主构件是nexus-indexer-2.0.0.jar,该项目还会通过一些插件生成如nexus-indexer-2.0.0-javadoc.jar、nexus-indexer-2.0.0-sources.jar这样一些附属构件,其包含了Java文档和源代码。这时候,javadoc和sources就是这两个附属构件的classifier。这样,附属构件也就拥有了自己唯一的坐标。注意:不能直接定义项目的classifier,因为附属构件不是项目直接默认生成的,而是由附加的插件帮助生成。
项目构件的文件名是与坐标相对应的,一般的规则是artifactId-version[-classifier].packaging,[-classifier]表示可选。这里还要强调一点,packaging并非一定与构件扩展名对应,比如packaging为maven-plugin的构件扩展名为jar。
二 依赖详解
2.1 依赖的配置
<project>
...
<dependencies>
<dependency>
<groupId>...</groupId>
<artifactId>...</artifactId>
<version>...</version>
<type>...</type>
<scope>...</scope>
<optional>...</optional>
<exclusions>
<exclusion>
...
</exclusion>
...
</exlusions>
</dependency>
...
</dependencies>
...
</project>
Maven项目的<dependencies>元素可以包含一个或者多个denpendency元素,即可以声明一个或者多个项目依赖,而每个依赖又由以下几个元素定义:
type:依赖的类型,对应于项目坐标定义的packaging。大部分情况下,该元素不必声明,其默认值为jar。
scope:依赖的范围
optional:标记依赖是否可选
exclusions:用来排除传递性依赖
2.1 依赖的范围
在Maven中,依赖范围用元素scope表示。Maven项目在编译主代码的时候需要使用一套classpath;然而在编译和执行测试的时候会使用另外一套。依赖范围就是用来控制依赖与这三种classpath(编译classpath、测试classpath、运行classpath)的关系。Maven有以下几种依赖范围:
compile:编译依赖范围。如果没有指定,就会默认使用该依赖范围。该此依赖范围对于编译、测试、运行三种classpath都有效。典型的例子是spring-core,在编译、测试和运行的时候都需要使用该依赖。
test:测试依赖范围。该依赖范围只对于测试classpath有效,在编译主代码或者运行项目的时将无法使用此类依赖。典型的例子就是JUnit,它只有在编译测试代码及运行测试环境的时候才需要。
provided:已提供依赖范围。该依赖范围对于测试和运行class-path有效,但在运行时无效。典型的例子是servlet-api,编译和测试项目的时候需要该依赖,但在运行项目的时候,由于容器已经提供,就不需要Maven重复引入一遍。
runtime:运行时依赖范围。该范围依赖,对于运行和测试class-path有效,但在编译主代码时无效。典型的例子是JDBC驱动实现,项目主代码的编译只需要JDK提供的JDBC接口,只有在执行测试或者运行项目的时候才需要实现上述接口的具体的JDBC驱动。
system:系统依赖范围。该依赖与三种classpath的关系,和provided依赖范围完全一致。但是,使用system范围的依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库解析的,而且往往与本机系统绑定,可能造成构建的不可移植,因此应该谨慎使用。systemPath元素可以引用环境变量。如:
<dependency>
<groupId>javax.sql</groupId>
<artifactId>jdbc-stdext</artifactId>
<version>2.0</version>
<scope>system</scope>
<systemPath>${java.home}/lib/rt.jar</systemPath>
</dependency>
import: 导入依赖范围。该依赖范围不会对三种classPath产生实际的影响,我们将在后面的章节详细介绍该依赖。
2.2 传递性依赖
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifact>
<version>1.1.1</version>
</denpendency>
commons-logging没有声明依赖范围,那么其依赖范围就是默认的compile,而spring-core一般的依赖范围也是compile。A项目有一个compile范围的spring-core依赖,spring-core有一个compile范围的commons-logging依赖,那么commons-logging就会成为A项目的compile范围依赖,commons-logging是account-email的一个传递性依赖。
有了传递性依赖机制,在使用Spring Framework的时候就不用去考虑它依赖了什么,也不用担心引入多于的依赖。Maven会解析各个直接依赖的POM,将那些必要的间接依赖,以传递性依赖的形式引入到当前的项目之中。
假设A依赖与B,B依赖与C,我们说A对于B是第一直接依赖,B对于C是第二直接依赖,A对于C是传递性依赖。第一直接依赖的范围和第二直接依赖的范围决定了传递性依赖的范围。如下表所示,最左边一列表示第一直接依赖范围,最上面一行表示第二直接依赖范围,中间的交叉单元格则表示传递性依赖范围。
compile | test | provided | runtime | |
compile | compile | - | - | runtime |
test | test | - | - | test |
provided | provided | - | - | provided |
runtime | runtime | - | - | runtime |
2.3 依赖调解
Maven的传递性依赖机制,一方面大大简化和方便了依赖声明。但有时候造成问题时,我们需要知道该传递性依赖是从哪条依赖路径引入的。例如,项目A有这样的依赖关系:A->B->C->X(1.0)、A->D->X(2.0),X是A的传递性依赖,但是两条依赖路径上有两个版本的X,那么哪个X会被Maven解析使用呢?两个版本都被解析是不行的,因为会造成重复依赖。Maven依赖的第一原则是:路径最近者优先。该例中X(1.0)的路径长度为3,而X(2.0)的路径长度为2,因此X(2.0)会被解析使用。然而,当传递路径一样长的时候怎么解决呢?Maven又定义了依赖调解的第二原则:第一声明者优先。在依赖路径长度相等的前提下,在POM中依赖声明的顺序决定了谁会被解析使用,声明顺序最靠前的那个依赖优胜。
2.4 可选依赖
假设有以下状态的依赖:A->B、B->X(可选)、B->Y(可选)。根据传递性依赖的定义,如果所有这三个依赖的范围都是compile,那么X、Y就是A的compile范围传递性依赖。然而,由于这里X、Y是可选依赖,依赖将不会得以传递。使用可选依赖的原因可能是B实现了两个特性,其中的特性一依赖于X,特性二依赖于Y,而且这两个特性是互斥的,用户不可能同时使用这两个特性。比如B是一个持久层隔离工具包,它支持多种数据库,包括MySQL,PostgreSQL等,在构建工具包的时候,需要这两种数据库的驱动程序,但在使用这个工具包的时候,只会依赖一种数据库。
项目B的依赖声明见如下:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.juvenxu.mvnbook</groupId>
<artifactId>project-b</artifactId>
<version>1.0.0</version>
<dependencies>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.10</version>
<optional>true</optional>
</dependency>
<dependency>
<groupId>postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>8.4-701.jdbc3</version>
<optional>true</optional>
</dependency>
</dependencies>
</project>
在pom.xml中,使用 <optional> 元素表示mysql-connector-java和postgresql这两个依赖为可选依赖,它们只对当前项目B产生影响,当其他项目依赖于B的时候,这两个依赖不会被传递。因此,当项目A依赖于项目B的时候,如果其实际使用基于MySql数据库,那么在A项目中就想要显示地声明mysql-connector-java这一依赖,见下面A项目pom.xml。
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.juvenxu.mvnbook</groupId>
<artifactId>project-a</artifactId>
<version>1.0.0</version>
<dependencies>
<dependency>
<groupId>com.juvenxu.mvnbook</groupId>
<artifactId>project-b</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>8.4-701.jdbc3</version>
</dependency>
</dependencies>
</project>
2.5 排除依赖
传递性依赖虽然简化了项目依赖的管理,但也会带来一些问题,需要我们排除一些传递性依赖。例如:当前项目有一个第三方依赖,而这个第三方依赖依赖了另一个类库的SNAPSHOT版本,那么这个SNAPSHOT就会成为当前项目的传递性依赖,SNAPSHOT表明当前项目正处于开发状态,具有很不好的稳定性,会直接影响到当前项目。这时候就需要排除掉该SNAPSHOT,并且在当前的项目中声明该类库的某个正式发布的版本。<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.juvenxu.mvnbook</groupId>
<artifactId>project-a</artifactId>
<version>1.0.0</version>
<dependencies>
<dependency>
<groupId>com.juvenxu.mvnbook</groupId>
<artifactId>project-b</artifactId>
<version>1.0.0</version>
<exclusions>
<exclusion>
<groupId>com.juvenxu.mvnbook</groupId>
<artifactId>project-c</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.juvenxu.mvnbook</groupId>
<artifactId>project-c</artifactId>
<version>1.1.0</version>
</dependency>
</dependencies>
</project>
2.6 归类依赖
很多时候,我们会使用到来自同一项目下的不同模块,而且这些依赖的版本都是相同的。例如我们在使用spring framework时,分别引入的依赖为org.springframework:spring-core:2.5.6、org.springframework:spring-beans:2.5.6、org.springframework:spring-context:2.5.6、org.springframework:spring-support:2.5.6。如果将来需要升级Spring Frame-work,这些依赖的版本会一起升级。在Maven中可以使用归类依赖,这样可以避免重复,而且在修改值的时候,能够降低错误发生的几率。例子如下:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.juvenxu.mvnbook</groupId>
<artifactId>account-email</artifactId>
<name>Account Email</name>
<version>1.0.0-SNAPSHOT</version>
<properties>
<springframework.version>2.5.6</springframework.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${springframework.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>${springframework.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${springframework.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-support</artifactId>
<version>${springframework.version}</version>
</dependency>
</dependencies>
</project>