第三章Maven依赖的特性-基础篇

Maven依赖核心配置文件pom.xml

POM：Project Object Model，项目对象模型。和 POM 类似的是：DOM（Document Object Model），文档对象模型。它们都是模型化思想的具体体现。

POM 表示将工程抽象为一个模型，再用程序中的对象来描述这个模型。这样我们就可以用程序来管理项目了。我们在开发过程中，最基本的做法就是将现实生活中的事物抽象为模型，然后封装模型相关的数据作为一个对象，这样就可以在程序中计算与现实事物相关的数据。

POM 理念集中体现在 Maven 工程根目录下 pom.xml 这个配置文件中。所以这个 pom.xml 配置文件就是 Maven 工程的核心配置文件。其实学习 Maven 就是学这个文件怎么配置，各个配置有什么用。

<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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0modelVersion>

<groupId>com.examplegroupId>
<artifactId>demoartifactId>
<version>0.0.1-SNAPSHOTversion>
<name>demoname>
<description>Demo project for Spring Bootdescription>




<packaging>jarpackaging>
<properties>
    
    <project.build.sourceEncoding>UTF-8project.build.sourceEncoding>
properties>

<dependencies>
    
    <dependency>
        
        <groupId>junitgroupId>
        <artifactId>junitartifactId>
        <version>4.12version>
        
        <scope>testscope>
    dependency>
dependencies>
    
project>

• XML报文头：指定了文档版本和编码方式
• project:所有pom文档的根元素，同时声明了一些pom相关的命令空间及xsd对象
• modelVersion:指定了当前POM模型的版本，对应maven2和maven3只是是4.0.0

依赖的范围

概念

标签的位置：dependencies/dependency/scope

使用 Maven 最主要的就是使用它的依赖管理功能，引入依赖存在一个范围，用scope来标识范围，maven 的依赖范围包括： compile，provide，runtime，test，system

compile 和 test 对比

	main目录（空间）	test目录（空间）	开发过程（时间）	部署到服务器（时间）
compile	有效	有效	有效	有效
test	无效	有效	有效	无效

compile 和 provided 对比

	main目录（空间）	test目录（空间）	开发过程（时间）	部署到服务器（时间）
compile	有效	有效	有效	有效
provided	有效	有效	有效	无效

结论

• compile：表示编译范围，指 A 在编译时依赖 B，该范围为默认依赖范围。编译范围的依赖会用在编译，测试，运行，由于运行时需要，所以编译范围的依赖会被打包。

  • 通常使用的第三方框架的 jar 包这样在项目实际运行时真正要用到的 jar 包都是以 compile 范围进行依赖的。比如 SSM 框架所需jar包。

• provided：provied 依赖只有当 jdk 或者一个容器已提供该依赖之后才使用。provide 依赖在编译和测试时需要。该范围不会被打包

  • provided：在开发过程中需要用到的“服务器上的 jar 包”通常以 provided 范围依赖进来。比如 servlet-api、jsp-api。而这个范围的 jar 包之所以不参与部署、不放进 war 包，就是避免和服务器上已有的同类 jar 包产生冲突，同时减轻服务器的负担。说白了就是：“服务器上已经有了，你就别带啦！”

• runtime：runtime 依赖在运行和测试运行时需要，但在编译时不需要。例如：jdbc 的驱动包。由于运行时需要，所以 runtime 范围的依赖会被打包。

• test：test 范围依赖在编译和运行时都不需要，只在测试编译和测试运行时需要。不参与打包

  • test：测试过程中使用的 jar 包，以 test 范围依赖进来。比如 junit。

• system：system 范围依赖与 provide 类似，但是必须显示的提供一个对于本地系统中 jar 文件的路径。一般不推荐使用。

而在实际开发中，我们常用的就是 compile、test、provided 。

测试

验证 compile 范围对 main 目录有效

main目录下的类：HelloServlet 使用compile范围导入的依赖：pro01-atguigu-maven

验证：使用compile范围导入的依赖对main目录下的类来说是有效的

有效：HelloServlet 能够使用 pro01-atguigu-maven 工程中的 Calculator 类

验证方式：在 HelloServlet 类中导入 Calculator 类，然后编译就说明有效。

验证test范围对main目录无效

测试方式：在主体程序中导入org.junit.Test这个注解，然后执行编译。

具体操作：在pro01-maven-java\src\main\java\com\atguigu\maven目录下修改Calculator.java

package com.atguigu.maven;
import org.junit.Test;
public class Calculator {
  public int sum(int i, int j){
    return i + j;
  }

}

执行Maven编译命令：

[ERROR] /D:/maven_workSpace/pro01-maven-java/src/main/java/com/atguigu/maven/Calculator.java:[2,17] 程序包org.junit不存在

验证test和provided范围不参与服务器部署

其实就是验证：通过compile范围依赖的jar包会放入war包，通过test范围依赖的jar包不会放入war包。

验证provided范围对测试程序有效

测试方式是在pro02-maven-web的测试程序中加入servlet-api.jar包中的类。

修改：pro02-maven-web\src\test\java\com\atguigu\maven\CalculatorTest.java

package com.atguigu.maven;

import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.ServletException;

import org.junit.Test;
import com.atguigu.maven.Calculator;

// 静态导入的效果是将Assert类中的静态资源导入当前类
// 这样一来，在当前类中就可以直接使用Assert类中的静态资源，不需要写类名
import static org.junit.Assert.*;

public class CalculatorTest{
  
  @Test
  public void testSum(){
    
    // 1.创建Calculator对象
    Calculator calculator = new Calculator();
    
    // 2.调用Calculator对象的方法，获取到程序运行实际的结果
    int actualResult = calculator.sum(5, 3);
    
    // 3.声明一个变量，表示程序运行期待的结果
    int expectedResult = 8;
    
    // 4.使用断言来判断实际结果和期待结果是否一致
    // 如果一致：测试通过，不会抛出异常
    // 如果不一致：抛出异常，测试失败
    assertEquals(expectedResult, actualResult);
    
  }
  
}

然后运行Maven的编译命令：mvn compile

然后看到编译成功。

依赖的传递

概念

A 依赖 B，B 依赖 C，那么在 A 没有配置对 C 的依赖的情况下，A 里面能不能直接使用 C？

传递的原则

在 A 依赖 B，B 依赖 C 的前提下，C 是否能够传递到 A，取决于 B 依赖 C 时使用的依赖范围。

• B 依赖 C 时使用 compile 范围：可以传递
• B 依赖 C 时使用 test 或 provided 范围：不能传递，所以需要这样的 jar 包时，就必须在需要的地方明确配置依赖才可以。

测试

使用 compile 范围依赖 spring-core

测试方式：让 pro01-maven-java 工程依赖 spring-core

具体操作：编辑 pro01-maven-java 工程根目录下 pom.xml

<dependency>
  <groupId>org.springframeworkgroupId>
  <artifactId>spring-coreartifactId>
  <version>4.0.0.RELEASEversion>
dependency>

使用 mvn dependency:tree 命令查看效果：

[INFO] com.atguigu.maven:pro01-maven-java:jar:1.0-SNAPSHOT
[INFO] +- junit:junit:jar:4.12:test
[INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] \- org.springframework:spring-core:jar:4.0.0.RELEASE:compile
[INFO] \- commons-logging:commons-logging:jar:1.1.1:compile

还可以在 Web 工程中，使用 mvn dependency:tree 命令查看效果（需要重新将 pro01-maven-java 安装到仓库）：

[INFO] com.atguigu.maven:pro02-maven-web:war:1.0-SNAPSHOT
[INFO] +- junit:junit:jar:4.12:test
[INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] +- javax.servlet:javax.servlet-api:jar:3.1.0:provided
[INFO] \- com.atguigu.maven:pro01-maven-java:jar:1.0-SNAPSHOT:compile
[INFO] \- org.springframework:spring-core:jar:4.0.0.RELEASE:compile
[INFO] \- commons-logging:commons-logging:jar:1.1.1:compile

验证 test 和 provided 范围不能传递

从上面的例子已经能够看到，pro01-maven-java 依赖了 junit，但是在 pro02-maven-web 工程中查看依赖树的时候并没有看到 junit。

要验证 provided 范围不能传递，可以在 pro01-maven-java 工程中加入 servlet-api 的依赖。

<dependency>
  <groupId>javax.servletgroupId>
  <artifactId>javax.servlet-apiartifactId>
  <version>3.1.0version>
  <scope>providedscope>
dependency>

效果还是和之前一样：

[INFO] com.atguigu.maven:pro02-maven-web:war:1.0-SNAPSHOT
[INFO] +- junit:junit:jar:4.12:test
[INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] +- javax.servlet:javax.servlet-api:jar:3.1.0:provided
[INFO] \- com.atguigu.maven:pro01-maven-java:jar:1.0-SNAPSHOT:compile
[INFO] \- org.springframework:spring-core:jar:4.0.0.RELEASE:compile
[INFO] \- commons-logging:commons-logging:jar:1.1.1:compile

依赖的排除

当 A 依赖 B，A 依赖 C，B可以传递X-1.0.jar到A, 而且 C 可以传递X-2.0.jar到 A 的时候

• A就同时导入了X-1.0.jar和X-2.0.jar,可能就会导致JAR包冲突

A 不想要 B中的X-1.0.jar，需要在 A 里面把 B的X-1.0.jar排除掉。而往往这种情况都是为了避免 jar 包之间的冲突。

• 虽然A不会把B的X-1.0.jar引进来，但是不会影响B工程依赖X-1.0.jar

测试

[INFO] com.atguigu.maven:pro01-maven-java:jar:1.0-SNAPSHOT
[INFO] +- junit:junit:jar:4.12:test
[INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] \- org.springframework:spring-core:jar:4.0.0.RELEASE:compile
[INFO] \- commons-logging:commons-logging:jar:1.1.1:compile

• pro01-maven-java中依赖了org.springframework:spring-core:jar:4.0.0.RELEASE:compile
  • org.springframework:spring-core:jar:4.0.0.RELEASE:compile依赖了commons-logging:commons-logging:jar:1.1.1:compile

配置

一般通过使用excludes标签配置依赖的排除：

<dependency>
  <groupId>com.atguigu.mavengroupId>
  <artifactId>pro01-maven-javaartifactId>
  <version>1.0-SNAPSHOTversion>
  <scope>compilescope>
  
  <exclusions>
    
    <exclusion>
      
      <groupId>commons-logginggroupId>
      <artifactId>commons-loggingartifactId>
    exclusion>
  exclusions>
dependency>

运行 mvn dependency:tree 命令查看效果

[INFO] com.atguigu.maven:pro02-maven-web:war:1.0-SNAPSHOT
[INFO] +- junit:junit:jar:4.12:test
[INFO] |  \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] +- javax.servlet:javax.servlet-api:jar:3.1.0:provided
[INFO] \- com.atguigu.maven:pro01-maven-java:jar:1.0-SNAPSHOT:compile
[INFO]    \- org.springframework:spring-core:jar:4.0.0.RELEASE:compile

发现在 spring-core 下面就没有 commons-logging 了。

项目的继承

概念

Maven工程之间，A 工程继承 B 工程

• B 工程：父工程
• A 工程：子工程

本质上是 A 工程的 pom.xml 中的配置继承了 B 工程中 pom.xml 的配置。

作用

在父工程中统一管理项目中的依赖信息，具体来说是管理依赖信息的版本。

它的背景是：

• 对一个比较大型的项目进行了模块拆分。
• 一个 project 下面，创建了很多个 module。
• 每一个 module 都需要配置自己的依赖信息。

它背后的需求是：

• 在每一个 module 中各自维护各自的依赖信息很容易发生出入，不易统一管理。
• 使用同一个框架内的不同 jar 包，它们应该是同一个版本，所以整个项目中使用的框架版本需要统一。
• 使用框架时所需要的 jar 包组合（或者说依赖信息组合）需要经过长期摸索和反复调试，最终确定一个可用组合。这个耗费很大精力总结出来的方案不应该在新的项目中重新摸索。

通过在父工程中为整个项目维护依赖信息的组合既保证了整个项目使用规范、准确的 jar 包；又能够将以往的经验沉淀下来，节约时间和精力。

举例

在一个工程中依赖多个 Spring 的 jar 包

[INFO] +- org.springframework:spring-core:jar:4.0.0.RELEASE:compile
[INFO] | \- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] +- org.springframework:spring-beans:jar:4.0.0.RELEASE:compile
[INFO] +- org.springframework:spring-context:jar:4.0.0.RELEASE:compile
[INFO] +- org.springframework:spring-expression:jar:4.0.0.RELEASE:compile
[INFO] +- org.springframework:spring-aop:jar:4.0.0.RELEASE:compile
[INFO] | \- aopalliance:aopalliance:jar:1.0:compile

使用 Spring 时要求所有 Spring 自己的 jar 包版本必须一致。为了能够对这些 jar 包的版本进行统一管理，我们使用继承这个机制，将所有版本信息统一在父工程中进行管理。

操作

创建父工程

创建的过程和前面创建 pro01-maven-java 一样。

工程名称：pro03-maven-parent

工程创建好之后，要修改它的打包方式：

  com.atguigu.maven
  pro03-maven-parent
  1.0-SNAPSHOT

  
  pom

只有打包方式为 pom 的 Maven 工程能够管理其他 Maven 工程。打包方式为 pom 的 Maven 工程中不写业务代码，它是专门管理其他 Maven 工程的工程。

创建模块工程

模块工程类似于 IDEA 中的 module，所以需要进入 pro03-maven-parent 工程的根目录，然后运行 mvn archetype:generate 命令来创建模块工程。

假设，我们创建三个模块工程：

查看被添加新内容的父工程 pom.xml

下面 modules 和 module 标签是聚合功能的配置

  
  pro04-maven-module
  pro05-maven-module
  pro06-maven-module

解读子工程的pom.xml

  
  com.atguigu.maven
  pro03-maven-parent
  1.0-SNAPSHOT





pro04-maven-module

在父工程中配置依赖的统一管理

  
    
      org.springframework
      spring-core
      4.0.0.RELEASE
    
    
      org.springframework
      spring-beans
      4.0.0.RELEASE
    
    
      org.springframework
      spring-context
      4.0.0.RELEASE
    
    
      org.springframework
      spring-expression
      4.0.0.RELEASE
    
    
      org.springframework
      spring-aop
      4.0.0.RELEASE
    
  

子工程中引用那些被父工程管理的依赖

关键点：省略版本号

  
    org.springframework
    spring-core
  
  
    org.springframework
    spring-beans
  
  
    org.springframework
    spring-context
  
  
    org.springframework
    spring-expression
  
  
    org.springframework
    spring-aop
  

在父工程中升级依赖信息的版本

……
      
        org.springframework
        spring-beans
        4.1.4.RELEASE
      
……

然后在子工程中运行mvn dependency:list，效果如下：

[INFO] org.springframework:spring-aop:jar:4.1.4.RELEASE:compile  
[INFO] org.springframework:spring-core:jar:4.1.4.RELEASE:compile  
[INFO] org.springframework:spring-context:jar:4.1.4.RELEASE:compile  
[INFO] org.springframework:spring-beans:jar:4.1.4.RELEASE:compile  
[INFO] org.springframework:spring-expression:jar:4.1.4.RELEASE:compile

在父工程中声明自定义属性

  UTF-8
  
  4.3.6.RELEASE

在需要的地方使用${}的形式来引用自定义的属性名：

    org.springframework
     spring-core
     ${atguigu.spring.version}

真正实现“一处修改，处处生效”。

实际意义

编写一套符合要求、开发各种功能都能正常工作的依赖组合并不容易。如果公司里已经有人总结了成熟的组合方案，那么再开发新项目时，如果不使用原有的积累，而是重新摸索，会浪费大量的时间。为了提高效率，我们可以使用工程继承的机制，让成熟的依赖组合方案能够保留下来。

如上图所示，公司级的父工程中管理的就是成熟的依赖组合方案，各个新项目、子系统各取所需即可。

聚合

聚合本身的含义

部分组成整体

Maven 中的聚合

使用一个“总工程”将各个“模块工程”汇集起来，作为一个整体对应完整的项目。

• 项目：整体
• 模块：部分

概念的对应关系：

从继承关系角度来看：
●父工程
●子工程

从聚合关系角度来看：
●总工程
●模块工程

好处

• 一键执行 Maven 命令：很多构建命令都可以在“总工程”中一键执行。

  以 mvn install 命令为例：Maven 要求有父工程时先安装父工程；有依赖的工程时，先安装被依赖的工程。我们自己考虑这些规则会很麻烦。但是工程聚合之后，在总工程执行 mvn install 可以一键完成安装，而且会自动按照正确的顺序执行。

• 配置聚合之后，各个模块工程会在总工程中展示一个列表，让项目中的各个模块一目了然。

聚合的配置

在总工程中配置 modules 即可：

    
    pro04-maven-module
    pro05-maven-module
    pro06-maven-module
  

依赖循环问题

如果 A 工程依赖 B 工程，B 工程依赖 C 工程，C 工程又反过来依赖 A 工程，那么在执行构建操作时会报下面的错误：

[ERROR] [ERROR] The projects in the reactor contain a cyclic reference:

这个错误的含义是：循环引用。

其他核心概念

生命周期

作用

为了让构建过程自动化完成，Maven 设定了三个生命周期，生命周期中的每一个环节对应构建过程中的一个操作。

三个生命周期

生命周期名称	作用	各个环节
Clean	清理操作相关	pre-clean clean post-clean
Site	生成站点相关	pre-site site post-site deploy-site
Default	主要构建过程	validate generate-sources process-sources generate-resources process-resources 复制并处理资源文件，至目标目录，准备打包。 compile 编译项目 main 目录下的源代码。 process-classes generate-test-sources process-test-sources generate-test-resources process-test-resources 复制并处理资源文件，至目标测试目录。 test-compile 编译测试源代码。 process-test-classes test 使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署。 prepare-package package 接受编译好的代码，打包成可发布的格式，如JAR。 pre-integration-test integration-test post-integration-test verify install将包安装至本地仓库，以让其它项目依赖。 deploy将最终的包复制到远程的仓库，以让其它开发人员共享；或者部署到服务器上运行（需借助插件，例如：cargo）。

特点

• 前面三个生命周期彼此是独立的。
• 在任何一个生命周期内部，执行任何一个具体环节的操作，都是从本周期最初的位置开始执行，直到指定的地方。（本节记住这句话就行了，其他的都不需要记）

Maven 之所以这么设计其实就是为了提高构建过程的自动化程度：让使用者只关心最终要干的即可，过程中的各个环节是自动执行的。

插件和目标

插件

Maven 的核心程序仅仅负责宏观调度，不做具体工作。具体工作都是由 Maven 插件完成的。例如：编译就是由 maven-compiler-plugin-3.1.jar 插件来执行的。

目标

一个插件可以对应多个目标，而每一个目标都和生命周期中的某一个环节对应。

Default 生命周期中有 compile 和 test-compile 两个和编译相关的环节，这两个环节对应 compile 和 test-compile 两个目标，而这两个目标都是由 maven-compiler-plugin-3.1.jar 插件来执行的。

仓库

• 本地仓库：在当前电脑上，为电脑上所有 Maven 工程服务
• 远程仓库：需要联网
  • 局域网：我们自己搭建的 Maven 私服，例如使用 Nexus 技术。
  • Internet
    • 中央仓库
    • 镜像仓库：内容和中央仓库保持一致，但是能够分担中央仓库的负载，同时让用户能够就近访问提高下载速度，例如：Nexus aliyun

建议：不要中央仓库和阿里云镜像混用，否则 jar 包来源不纯，彼此冲突。

专门搜索 Maven 依赖信息的网站：https://mvnrepository.com/