转载:http://m.blog.csdn.net/article/details?id=50612701
了解Spring的朋友都知道,创建一个Spring Framework项目都需要依赖什么样的Jar包。如果不使用Maven,那么在项目中就需要手动下载相关的依赖。由于Spring Framework又会依赖与其他开源类库,因此实际中往往会下载Spring Framework的jar包,还的下载所有它依赖的其他jar包。这么做往往就引入了很多不必要的依赖。另一种做法是只下载Spring Framework的jar包,不包含其他的相关依赖,到实际使用的时候,再根据报错信息,或者查询相关文档,加入需要的其他依赖。这么做让我们非常不舒服。
1. 传递性依赖
Maven的传递性依赖机制可以很好的解决这一问题。我们还是以HelloWorld项目为例。我们可以从Eclipse创建Spring-HelloWorld项目过程与Maven创建Spring-HelloWorld项目过程看出差别来:
(1)Eclipse创建Spring-HelloWorld项目:
对于使用Spring2.xxx,我们需要下载spring-2.5.6.jar;对于Spring3.xxx,我们需要下载spring-context-4.2.4.RELEASE.jar,spring-core-4.2.4.RELEASE.jar。除此之外,我们还的下载Spring
Framework所依赖的其他的jar:commons-logging-1.2.jar。
(2)Maven创建Spring-HelloWorld项目:
但是使用Maven方式我们只需要知道Sring Framework的jar即可,不需要知道其所需要commons-logging等jar包。
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.sjf.springdemo</groupId>
<artifactId>springdemo-helloworld</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
<name>springdemo-helloworld</name>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>2.5.6</version>
</dependency>
</dependencies>
</project>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.sjf.springdemo</groupId>
<artifactId>springdemo-helloworld</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
<name>springdemo-helloworld</name>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>4.2.4.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>4.2.4.RELEASE</version>
</dependency>
</dependencies>
</project>
其以上代码是项目配置的依赖,从上面可以看出我们只依赖了Spring Framework的jar,并没有依赖commons-logging。
但是我们从Maven项目上看到Maven的依赖:
Spring2.xxx
Spring3.xxx
从上面可以看出我们虽然只依赖了Spring Framework的jar,并没有依赖其他类库的jar,但是项目还是出现了其他的jar。这就是传递性依赖的作用。
下图是上面实例项目的依赖演示图:
那到底什么是传递性依赖呢?
传递性依赖是在maven2中添加的新特征,这个特征的作用就是你不需要考虑你依赖的库文件所需要依赖的库文件,能够将依赖模块的依赖自动的引入。 例如我们依赖于spring的库文件,但是spring本身也有依赖,如果没有传递性依赖那就需要我们了解spring项目依赖,自己添加到我们的项目中。 |
有了传递性依赖机制,在使用Spring Framework的时候就不用去考虑它依赖了什么,也不用担心引入多余的依赖。Maven会解析各个直接依赖的POM,将那些必要的间接依赖,以传递性依赖的形式引入到当前的项目中。
2.传递性依赖与依赖范围
依赖范围不仅可以控制依赖与三种classpath的关系,还对传递性依赖产生影响。上面例子中,springdemo-helloworld对于spring-core的依赖范围是compile,spring-core对于commons-logging的依赖范围是compile,那么springdemo-helloworld对于commons-logging这一传递性依赖的范围也就是compile。假设A依赖于B,B依赖于C,我们说A对于B是第一直接依赖,B对C是第二直接依赖,A对于C是传递性依赖。第一直接依赖的范围和第二直接依赖的范围决定了传递性依赖的范围。
最左边一行表示第一直接依赖范围,最上面一行表示第二直接依赖范围,中间的交叉单元格则表示传递性依赖范围。
compile | test | provided | runtime | |
compile | compile | — | — | runtime |
test | test | — | — | test |
provided | provided | — | provided | provided |
runtime | runtime | — | — | runtime |
仔细观察上面表格,我们发现这样的规律:
当第二直接依赖的范围是compile的时候,传递性依赖的范围与第一直接依赖的范围一致;
当第二直接依赖的范围是test的时候,依赖不会得以传递;
当第二直接依赖的范围是provided的时候,只传递第一直接依赖的范围也为provided的依赖,切传递性依赖的范围同样为provided;
当第二直接依赖的范围是runtime的时候,传递性依赖的范围与第一直接依赖的范围一致,但compile例外,此时传递性依赖的范围为runtime。