Maven学习笔记（二）：Maven依赖

依赖是Maven中最关键的部分，使用Maven管理项目很大的原因是因为他的依赖管理功能。

全部章节传送门：
Maven学习笔记（一）：Maven概述
Maven学习笔记（二）：Maven依赖
Maven学习笔记（三）：POM文件
Maven学习笔记（四）：Maven仓库
Maven学习笔记（五）：Maven插件

在工程中引入某个jar包，只需要在pom.xml中引入jar包的坐标，比如引入log4j的依赖：

<dependencies>
    <dependency>
        <groupId>log4j</groupId>
        <artifactId>log4j</artifactId>
        <version>1.2.17</version>
        <scope>compile</scope>
    </dependency>
</dependencies>

Maven通过groupId、artifactId与version三个向量来定位Maven仓库其jar包所在的位置，并把对应的jar包引入到工程中来。

依赖范围

maven 项目不同的阶段引入到classpath中的依赖是不同的，例如，编译时，maven 会将与编译相关的依赖引入classpath中，测试时，maven会将测试相关的的依赖引入到classpath中，运行时，maven会将与运行相关的依赖引入classpath中，而依赖范围就是用来控制依赖于这三种classpath的关系。

前面的例子中，scope标签就是依赖范围的配置。该项默认配置compile,可选配置还有test、provided、runtime、system、import，其中compile、test和provided使用较多，下面依次介绍。

编译依赖范围（compile）

该范围就是默认依赖范围，此依赖范围对于编译、测试、运行三种classpath都有效，举个简单的例子，假如项目中有spring-core的依赖，那么spring-core不管是在编译，测试，还是运行都会被用到，因此spring-core必须是编译范围（构件默认的是编译范围，所以依赖范围是编译范围的无须显示指定）

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>2.5</version>
    <scope>compile</scope> <!--默认为该依赖范围，无须显示指定-->
</dependency>

测试依赖范围(test)

使用此依赖范围的依赖，只对测试classpath有效，在编译主代码和项目运行时，都将无法使用该依赖，最典型的例子就是 Junit, 构件在测试时才需要，所以它的依赖范围是测试，因此它的依赖范围需要显示指定为<scope>test</scope>,当然不显示指定依赖范围也不会报错，但是该依赖会被加入到编译和运行的classpath中,造成不必要的浪费 。

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

已提供依赖范围(provided)

使用该依赖范围的maven依赖，只对编译和测试的classpath有效，对运行的classpath无效，典型的例子就是servlet-api， 编译和测试该项目的时候需要该依赖，但是在运行时，web容器已经提供的该依赖，所以运行时就不再需要此依赖，如果不显示指定该依赖范围，并且容器依赖的版本和maven依赖的版本不一致的话，可能会引起版本冲突，造成不良影响。

<dependency>
    <groupId>javax-servlet</groupId>
    <artifactId>servlet-api</artifactId>
    <version>2.0</version>
    <scope>provided</scope>
</dependency>

运行时依赖范围(runtime)

使用该依赖范围的maven依赖，只对测试和运行的classpath有效，对编译的classpath无效，典型例子就是JDBC的驱动实现，项目主代码编译的时候只需要JDK提供的JDBC接口，只有在测试和运行的时候才需要实现上述接口的具体JDBC驱动。

系统依赖范围（system）

该依赖与classpath的关系与provided依赖范围完全一致，但是系统依赖范围必须通过配置systemPath元素来显示指定依赖文件的路径，此类依赖不是由maven仓库解析的，而且往往与本机系统绑定，可能造成构件的不可移植，因此谨慎使用，systemPath元素可以引用环境变量：

<dependency>
    <groupId>javax.sql</groupId>
    <artifactId>jdbc-stext</artifactId>
    <version>2.0</version>
    <scope>system</scope>
    <systemPath>${java.home}/lib/rt.jar</systemPath> 
</dependency>

导入依赖范围(import)

该依赖范围不会对三种classpath产生影响，该依赖范围只能与dependencyManagement元素配合使用，其功能为将目标pom文件中dependencyManagement的配置导入合并到当前pom的dependencyManagement中。有关dependencyManagement的功能会在Maven继承特性部分说明。

依赖的传递

依赖的传递性指：在A中添加对B的依赖，在B中添加对C的依赖，如果依赖范围是compile的，A不仅会有B的jar 包，也会有C的jar 包。如果在C中添加了某个依赖，那么根据传递性，A和B也可以使用C添加的依赖，而不需要自己再重新引入依赖。

依赖传递的原则：

• 最短路径优先原则：如果A依赖于B，B依赖于C，在B和C 中同时有log4j的依赖，并且这两个版本不一致，那么A会根据最短路径原则，在A中会传递过来B的log4j版本。
• 路径相同先声明原则：如果在A同时依赖于B和C，B和C没有依赖关系，并且都有log4j的依赖，且版本不一致，那么A会引入在pom.xml中先声明依赖的log4j版本。

依赖的排除

我们在当前工程中引入了A的依赖，而A同时有对B的依赖，根据传递性我们知道，在当前工程中会自动引入对B的依赖。如果我们不想引入对B的依赖，我们就需要在引入对A依赖的同时排除对B的依赖。

下面我们以spring-core为例，当我们在pom.xml中引入对spring-core 的同时，会自动将commons-logging 的jar 包引入进来，如果我们不想引入commons-logging，就可以进行如下配置：

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>4.3.14.RELEASE</version>

        <exclusions>
            <exclusion>
                <artifactId>commons-logging</artifactId>
                <groupId>commons-logging</groupId>
            </exlcusion>
        </exclusions>
    </dependency>
</dependencies>

聚合和继承

将多个项目同时运行就称为聚合。只需在pom文件中作如下配置即可实现聚合：

<modules>
    <module>web-connection-pool</module>
    <module>web-java-crawler</module>
</modules>

另外，聚合模块的打包方式必须为pom，否则无法完成构建。

在聚合多个项目时，如果这些被聚合的项目中需要引入相同的Jar，那么可以将这些Jar写入父pom中，各个子项目继承该pom即可。，父模块的打包方式必须为pom，否则无法构建项目。

通过在各个子模块中配置来表明其继承与哪一个父模块：

<parent>
   <groupId>com.baidu</groupId>
   <artifactId>miliao-rootpom</artifactId> 
   <version>2.0.3</version>
</parent>

继承的POM元素如下：

• groupId：项目组ID，项目坐标的核心元素
• version：项目版本，项目坐标的核心因素
• description：项目的描述信息
• organization：项目的组织信息
• inceptionYear：项目的创始年份
• url：项目的URL地址
• developers：项目的开发者信息
• contributors：项目的贡献者信息
• distributionManagement：项目的部署配置
• issueManagement：项目的缺陷跟踪系统信息
• ciManagement：项目的持续集成系统信息
• scm：项目的版本控制系统
• malilingLists：项目的邮件列表信息
• properties：自定义的Maven属性
• dependencies：项目的依赖配置
• dependencyManagement：项目的依赖管理配置
• repositories：项目的仓库配置
• build：包括项目的源码目录配置、输出目录配置、插件配置、插件管理配置等
• reporting：包括项目的报告输出目录配置、报告插件配置等