排除依赖
传递性依赖会给项目隐式地引入很多依赖,着极大简化了项目依赖的管理,但是有些时候这种特性也会带来问题。例如,当前项目有一个第三方依赖,而这个第三方依赖由于某些原因依赖了另一个类库的SNAPSHOT版本,那么这个SNAPSHOT就会成为当前项目的传递性依赖,而SNAPSHOT的不稳定性会直接影响到当前的项目。这时就需要排除掉该SNAPSHOT,并且在当前项目中声明该类库的某个正式发布的版本。还有一些情况,你可能也想要替换掉某个传递性依赖,比如Sun JTA API,Hibernate依赖与这个JAR,但是由于版权的因素,该类库不在中央仓库中,而Apache Geronimo项目有一个对应的实现。这时你就可以排除Sun JAT API,而声明Geronimo的JTA API实现。
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.cc.maven</groupId>
<artifactId>project-a</artifactId>
<version>1.0.0</version>
<packaging>jar</packaging>
<dependencies>
<dependency>
<groupId>com.cc.maven</groupId>
<artifactId>project-b</artifactId>
<version>1.0.0</version>
<exclusions>
<exclusion>
<groupId>com.cc.maven</groupId>
<artifactId>project-c</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.cc.maven</groupId>
<artifactId>project-b</artifactId>
<version>1.1.0</version>
</dependency>
</dependencies>
</project>
上述代码中,项目A依赖于项目B,但是由于一些原因,不想引入传递性依赖C,而是自己显式声明对项目C 1.1.0版本的依赖。代码中使用exclusions元素声明排除依赖,exclusions可以包含一个或者多个exclusion子元素,因此可以排除一个或者多个传递性依赖。需要注意的是,声明exclusion的时候只需要groupId和artifactId,而不需要version元素,这是因为只需要groupId和artifactId就能唯一定位依赖图中的某个依赖。换句话说,maven解析后的依赖中,不可能出现groupId和artifactId项目,但是version不同的两个依赖。该例的依赖解析逻辑如下所示:
归类依赖
关于Spring Framework的依赖有很多,他们来自同一个项目的不同模块。因此所有这些依赖的版本都是相同的,可以知道,如果将来想要升级Spring Framework的话,这些依赖版本也会一起升级。这一情况在java中也似曾相识,考虑代码如下:
public double c(double r){
return 2 * 3.14 * r;
}
public double s(double r){
return 3.14 * r * r;
}
这两个简单的方程式计算圆的周长和面积,有经验的程序员一眼就能看出问题,使用字面量3.14显然不合适,应该定义一个常量并在方法中使用,如下:
public final double PI = 3.14;
public double c(double r){
return 2 * PI * r;
}
public double s(double r){
return PI * r * r;
}
使用常量不仅可以使代码变得更加简洁,更重要的是可以避免重复,只需要更改一处,降低了错误的概率。
使用maven属性归类依赖:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.juven.mvnbook.account</groupId>
<artifactId>account-email</artifactId>
<version>1.0.0-SNAPSHOT</version>
<name>Account Email</name>
<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-context</artifactId>
<version>${springframework.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context-support</artifactId>
<version>${springframework.version}</version>
</dependency>
</dependencies>
</project>
这里简单使用到了Maven的属性,首先使用properties元素定义了Maven的属性,该例子中定义了一个springframework.version子元素,其值为2.5.6,有了这个属性之后,Maven运行的时候,会将POM中所有${springframework.version}替换成2.5.6,也就是说,可以使用${}的方式来引用Maven的属性,然后将所有Spring Framework依赖的版本值用这一属性引用。这个和在java中常量PI替换3.14是同样的道理,只是语法不同而已。
优化依赖
在软件开发的过程中,程序员会通过重构等方式不断地优化自己的代码,使其变得更简洁、更灵活。同理,程序员也应该能够对maven项目的依赖了然于胸,并对其优化,如去除多余的依赖,显式声明某些必要的依赖。
maven会自动解析所有项目的直接依赖和传递性依赖,并且根据规则正确判断每个依赖的范围。对于一些依赖冲突,也能进行调解,以确保任何一个构件只能唯一的版本在依赖中存在。在这些工作之后,最后得到的那些依赖被称为已解析依赖。
可以通过运行如下命令查看当前项目的已解析依赖:mvn dependency:list
将直接在当前POM声明的依赖定义为顶层依赖,而这些顶层依赖的依赖则定义为第二层依赖,以此类推,有第三、第四层依赖。当这些依赖经过Maven解析之后,就会构成一个依赖树,通过这颗依赖树,就能够很清楚地看到某个依赖是通过哪条路径引入的。可以运行如下命令查看当前项目的依赖树:mvn dependency:tree
使用mvn dependency:list和mvn dependency:tree可以帮助我们详细了解项目中所有的依赖的具体详细,在此基础上,还有mvn dependency:analyze工具可以帮助分析当前项目的依赖