[Maven学习笔记4]Maven依赖特性

[Maven学习笔记四]Maven依赖特性

三个模块

为了说明问题，以用户登陆小web应用为例。通常一个web应用分为三个模块，模型和数据持久化层user-core, 业务逻辑层user-service以及web展现层user-web，

user-service依赖于user-core

user-web依赖于user-core和user-service

依赖作用范围

Maven的dependency定义了scope元素，用于控制依赖的部署

        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.11</version>
            <scope>test</scope>
        </dependency>

1.compile
编译范围，默认scope，在工程环境的classpath（编译环境）和打包（如果是WAR包，会包含在WAR包中）时候都有效。

compile表示依赖在编译的时候加载，编译，测试和打包都有效

2.provided
提供范围，表示该依赖包已经由目标容器（如tomcat）和JDK提供，只在编译和测试的classpath中加载和使用，打包的时候不会包含在目标包中。

最常见的是j2ee规范相关的servlet-api和jsp-api等jar 包，一般由servlet容器提供，无需在打包到war 包中，如果不配置为provided，把这些包打包到工程war包中，在tomcat6以上版本会出现冲突无法正常运行程序（版本不符的情况）

打包的时候无效，编译和测试的时候有效

3.runtime
一般是运行和测试环境使用，编译时候不用加入classpath，打包时候会打包到目标包中。一般是通过动态加载或接口反射加载的情况比较多。也就是说程序只使用了接口，具体的时候可能有多个，运行时通过配置文件或jar包扫描动态加载的情况。典型的包括：JDBC驱动等。

编译时无效，测试和打包的时候有效

4.test
测试范围，一般是单元测试场景使用，在编译环境加入classpath，但编译mvn compile, 打包mvn package不会加入，如junit,dbunit等。

只有在编译src/test目录下的类是才会使用scope为test的依赖

编译和打包无效，测试有效

5.system
系统范围，与provided类似，只是标记为该scope的依赖包需要明确指定基于文件系统的jar包路径。因为需要通过systemPath 指定本地jar文件路径，所以该scope是不推荐的。如果是基于组织的，一般会建立本地镜像，会把本地的或组织的基础组件加入本地镜像管理，避过使用该 scope的情况。

6.import

依赖传递

当在user-service模块的pom.xml文件中添加了对user-core的依赖后，Maven自动将user-core这个模块的pom.xml中声明的依赖加入到user-core的classpath上。注意：添加的依赖只是在user-core中scope声明为compile范围的，其他的范围例如test，则不会进行依赖传递

传递依赖版本的选择(Case1)

假如有三个模块A，B和C，以及另一个模块X,例如junit

A依赖于junit的3.8.2版本，B依赖于junit的4.11版本，同时A和B对junit的依赖scope都是compile而不是test(这里仅仅用于说明问题，不必拘泥于这种对junit设置为compile的情况不存在)

这种情况常见，比如X模块是log4j，很多模块都会依赖于log4j

那么当C依赖于A和B时，A和B依赖的junit都要传递给C，那么最终传递给C的junit究竟是哪个版本？答案是，在C的pom.xml中，如果C直接添加了对X的依赖，那么无视A，B传递过来的X；如果C没有添加对X

的直接依赖，那么A和B依赖的junit都要传递给C，那么最终传递给C的junit究竟是哪个版本？答案是，在C的pom.xml中，先声明对哪个模块依赖，就取那个模块传递的依赖，因此C依赖的junit版本是A传递过来的3.8.2，而不是自作聪明的取B依赖的更高版本4.11

C->A->X

C->B->X

在依赖路径相同的情况下，去C中优先声明的那个依赖传递过来的依赖

传递依赖版本的选择(Case2)

假如有三个模块A，B和C，以及另外两个模块M，X

A间接依赖于X：A依赖于M，M依赖于X，那么M将X传递给A

B直接依赖于X

那么当C依赖于A和B时，A和B都会把版本X传给C，那么C添加classpath上的X是那个版本呢？不论C的pom文件如何定义对A，B依赖的顺序，C都会加载B传递的依赖，原因是C对X的依赖路径取最短的那个

C->A->M->X

C->B->X

传递依赖版本的控制

上面的Case1和Case2是Maven内置的依赖传递特性，通常，我们会有两方面的需求

1.在Case2中，我们不想依赖于B传递过来的X，就是想用A通过M间接传递过来的X

2.我们不希望加载通过传递产生的依赖包

Maven提供了在dependency中显式的排除某些包以阻止依赖传递，例如

        <dependency>
            <groupId>a</groupId>
            <artifactId>b</artifactId>
            <version>1.0</version>
            <exclusions>
                <exclusion>
                    <groupId>m</groupId>
                    <artifactId>n</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>x</groupId>
                    <artifactId>y</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

上面从<a,b,1.0>中删除了两个<a,b,1.0>依赖的<m,n>,<x,y>，因为每个模块只能依赖一个版本，因此不需要指定版本

[Maven学习笔记4]Maven依赖特性

相关推荐