Maven

Maven基础

能够使用Maven进行项目的管理

1，Maven

Maven是专门用于管理和构建Java项目的工具，它的主要功能有：

  • 提供了一套标准化的项目结构

  • 提供了一套标准化的构建流程（编译，测试，打包，发布……）

  • 提供了一套依赖管理机制

标准化的项目结构：

Maven提供了一套标准化的项目结构，所有的IDE使用Maven构建的项目完全一样，所以IDE创建的Maven项目可以通用。如下图右边就是Maven构建的项目结构。

image-20260305112118130

标准化的构建流程：

image-20210726154144488

如上图所示我们开发了一套系统，代码需要进行编译、测试、打包、发布，这些操作如果需要反复进行就显得特别麻烦，而Maven提供了一套简单的命令来完成项目构建。

依赖管理：

依赖管理其实就是管理你项目所依赖的第三方资源（jar包、插件）。如之前我们项目中需要使用JDBC和Druid的话，就需要去网上下载对应的依赖包（当前之前是老师已经下载好提供给大家了），复制到项目中，还要将jar包加入工作环境这一系列的操作。如下图所示

image-20210726154753631

而Maven使用标准的 坐标 配置来管理各种依赖，只需要简单的配置就可以完成依赖管理。

image-20210726154922337

如上图右边所示就是mysql驱动包的坐标，在项目中只需要写这段配置，其他都不需要我们担心，Maven都帮我们进行操作了。

市面上有很多构建工具，而Maven依旧还是主流构建工具，如下图是常用构建工具的使用占比

image-20210726155212733

1.1 Maven简介

Apache Maven 是一个项目管理和构建工具，它基于项目对象模型(POM)的概念，通过一小段描述信息来管理项目的构建、报告和文档。

官网 ：http://maven.apache.org/

Maven是一个工具即可。Apache 是一个开源组织，将来我们会学习很多Apache提供的项目。

Maven的作用：

  1. 方便的依赖管理
  2. 统一的项目结构
  3. 标准的项目构建流程

image.png

1.1.1 Maven模型

  • 项目对象模型 (Project Object Model)
  • 依赖管理模型(Dependency)
  • 插件(Plugin)
image-20210726155759621

如上图所示就是Maven的模型，而我们先看紫色框框起来的部分，他就是用来完成 标准化构建流程 。如我们需要编译，Maven提供了一个编译插件供我们使用，我们需要打包，Maven就提供了一个打包插件提供我们使用等。

image-20210726160928515

上图中紫色框起来的部分，项目对象模型就是将我们自己抽象成一个对象模型，有自己专属的坐标;

依赖管理模型则是使用坐标来描述当前项目依赖哪儿些第三方jar包;

上述Maven模型图中还有一部分是仓库。如何理解仓库呢？

1.1.2 仓库

大家想想这样的场景，我们创建Maven项目，在项目中使用坐标来指定项目的依赖，那么依赖的jar包到底存储在什么地方呢？
其实依赖jar包是存储在我们的本地仓库中。而项目运行时从本地仓库中拿需要的依赖jar包。

仓库分类：

  • 本地仓库：自己计算机上的一个目录

  • 中央仓库：由Maven团队维护的全球唯一的仓库

  • 远程仓库(私服)：一般由公司团队搭建的私有仓库

    今天我们只学习远程仓库的使用，并不会搭建。

当项目中使用坐标引入对应依赖jar包后，首先会查找本地仓库中是否有对应的jar包：

  • 如果有，则在项目直接引用;
  • 如果没有，则去中央仓库中下载对应的jar包到本地仓库。
image-20210726162605394

如果还可以搭建远程仓库，将来jar包的查找顺序则变为：

本地仓库 –> 远程仓库–> 中央仓库

image-20210726162815045 ### 1.2 Maven安装配置

  • 解压 apache-maven-3.8.8.rar 到任意目录既安装完成,进入解压后的文件夹的bin目录下执行 mvn -version的命令，出现如图所示表示安装成功

    image-20250611141317496

  • 配置本地仓库

1
修改 conf/settings.xml 中的 <localRepository> 为一个指定目录作为本地仓库，用来存储jar包。

  • 配置阿里云私服

    中央仓库在国外，所以下载jar包速度可能比较慢，而阿里公司提供了一个远程仓库，里面基本也都有开源项目的jar包。

1
修改 conf/settings.xml 中的 <mirrors>标签，为其添加如下子标签：
1
2
3
4
5
6
<mirror>  
    <id>alimaven</id>  
    <name>aliyun maven</name>  
    <url>http://maven.aliyun.com/nexus/content/groups/public/</url>
    <mirrorOf>central</mirrorOf>          
</mirror>

  • 配置jdk

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    <profile>
    	<id>jdk-17</id>
    	<activation>
    		<activeByDefault>true</activeByDefault>
    		<jdk>17</jdk>
    	</activation>
    	<properties>
    		<maven.compiler.source>17</maven.compiler.source>
    		<maven.compiler.target>17</maven.compiler.target>
    		<maven.compiler.compilerVersion>17</maven.compiler.compilerVersion>
    	</properties>
    </profile>

1.3 Maven基本使用

1.3.1 Maven 常用命令

  • compile ：编译
  • clean：清理
  • test：测试
  • package：打包
  • install：安装

Maven还提供了标准化的跨平台的自动化构建方式。

image.png

如上图所示我们开发了一套系统，代码需要进行编译、测试、打包、发布等过程，这些操作是所有项目中都需要做的，如果需要反复进行就显得特别麻烦，而Maven提供了一套简单的命令来完成项目构建。

image.png

通过Maven中的命令，就可以很方便的完成项目的编译(compile)、测试(test)、打包(package)、发布(deploy) 等操作。

而且这些操作都是跨平台的，也就是说无论你是Windows系统，还是Linux系统，还是Mac系统，这些命令都是支持的。

1.3.2 Maven 生命周期

Maven 构建项目生命周期描述的是一次构建过程经历经历了多少个事件

Maven 对项目构建的生命周期划分为3套：

  • clean ：清理工作。
  • default ：核心工作，例如编译，测试，打包，安装等。
  • site ： 产生报告，发布站点等。这套声明周期一般不会使用。

三套生命周期又包含哪些具体的阶段呢, 我们来看下面这幅图:

image.png

每套生命周期包含一些阶段（phase），阶段是有顺序的，后面的阶段依赖于前面的阶段。

我们看到这三套生命周期，里面有很多很多的阶段，这么多生命周期阶段，其实我们常用的并不多，主要关注以下几个：

  • clean：移除上一次构建生成的文件
  • compile：编译项目源代码
  • test：使用合适的单元测试框架运行测试(junit)
  • package：将编译后的文件打包，如：jar、war等
  • install：安装项目到本地仓库

Maven的生命周期是抽象的，这意味着生命周期本身不做任何实际工作。
在Maven的设计中，实际任务（如源代码编译）都交由插件来完成。

image.png

IDEA工具为了方便程序员使用maven生命周期，在右侧的maven工具栏中，已给出快速访问通道。

image.png

  • 生命周期的顺序是：clean –> validate –> compile –> test –> package –> verify –> install –> site –> deploy

说明： 在同一套生命周期中，我们在执行后面的生命周期时，前面的生命周期都会执行。
思考： 当运行package生命周期时，clean、compile生命周期会不会运行？

clean不会运行，compile会运行。 因为compile与package属于同一套生命周期，而clean与package不属于同一套生命周期。
同一套生命周期内，执行后边的命令，前面的所有命令会自动执行。例如默认（default）生命周期如下：

image-20210726173153576

当我们执行 install（安装）命令时，它会先执行 compile命令，再执行 test 命令，再执行 package 命令，最后执行 install 命令。

当我们执行 package （打包）命令时，它会先执行 compile 命令，再执行 test 命令，最后执行 package 命令。

默认的生命周期也有对应的很多命令，其他的一般都不会使用，我们只关注常用的;

1.4 IDEA使用Maven

以后开发中我们肯定会在高级开发工具中使用Maven管理项目，而我们常用的高级开发工具是IDEA，所以接下来我们会讲解Maven在IDEA中的使用。

1.4.1 IDEA配置Maven环境

我们需要先在IDEA中配置Maven环境：

image-20260305112423784

1.4.2 Maven 坐标详解

什么是坐标？

  • Maven 中的坐标是==资源的唯一标识==
  • 使用坐标来定义项目或引入项目中需要的依赖

Maven 坐标主要组成

  • groupId：定义当前Maven项目隶属组织名称（通常是域名反写，例如：com.itxg）
  • artifactId：定义当前Maven项目名称（通常是模块名称，例如 order-service、goods-service）
  • version：定义当前项目版本号

如下图就是使用坐标表示一个项目：

image-20210726174718176

==注意：==

  • 上面所说的资源可以是插件、依赖、当前项目。
  • 我们的项目如果被其他的项目依赖时，也是需要坐标来引入的。

1.4.3 IDEA 创建 Maven项目

  • 创建模块，选择Maven，点击Next

  • 填写模块名称，坐标信息，点击finish，创建完成

    创建好的项目目录结构如下：
    img

  • 编写 HelloWorld，并运行

1.4.4 IDEA 导入 Maven项目

大家在学习时可能需要看老师的代码，当然也就需要将老师的代码导入到自己的IDEA中。我们可以通过以下步骤进行项目的导入：

  • 方式一：File -> Project Structure -> Modules -> Import Module -> 选择maven项目的pom.xml。

image.png

  • 方式二：Maven面板 -> +（Add Maven Projects） -> 选择maven项目的pom.xml。

image.png

  • 如果没有Maven面板，选择

    View –> Appearance –> Tool Window Bars

可以通过下图所示进行命令的操作：

image-20210726182902961

配置 Maven Search 插件

image-20260305112540403

image-20260305112555927

1.4.5 pom文件详解

POM (Project Object Model) ：指的是项目对象模型，用来描述当前的maven项目。

  • 使用pom.xml文件来描述当前项目。 pom.xml文件如下：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<?xml version="1.0" encoding="UTF-8"?>
<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">
    <!-- POM模型版本 -->
    <modelVersion>4.0.0</modelVersion>

    <!-- 当前项目坐标 -->
    <groupId>com.itheima</groupId>
    <artifactId>maven-project01</artifactId>
    <version>1.0-SNAPSHOT</version>
    
    <!-- 项目的JDK版本及编码 -->
    <properties>
        <maven.compiler.source>17</maven.compiler.source>
        <maven.compiler.target>17</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

</project>

pom文件详解：

  • <project> ：pom文件的根标签，表示当前maven项目

  • <modelVersion>：声明项目描述遵循哪一个POM模型版本

    • 虽然模型本身的版本很少改变，但它仍然是必不可少的。目前POM模型版本是4.0.0

  • <maven.compiler.source> ：编译JDK的版本

  • <maven.compiler.target> ：运行JDK的版本

  • <project.build.sourceEncoding> : 设置项目的字符集

1.5 依赖管理

1.5.1 使用坐标引入jar包

使用坐标引入jar包的步骤：

  1. 在pom.xml中编写<dependencies>标签
  2. 在<dependencies>标签中使用<dependency>引入坐标
  1. 定义坐标的 groupId、artifactId、version
  • 点击刷新按钮，使坐标生效
    image.png

注意：

快捷方式导入jar包的坐标：

每次需要引入jar包，都去对应的网站进行搜索是比较麻烦的，接下来给大家介绍一种快捷引入坐标的方式

  • 在 pom.xml 中 按 alt + insert，选择 Dependency

  • 在弹出的面板中搜索对应坐标，然后双击选中对应坐标

  • 点击刷新按钮，使坐标生效

image.png

自动导入设置：

上面每次操作都需要点击刷新按钮，让引入的坐标生效。当然我们也可以通过设置让其自动完成

  • 选择 IDEA中 File –> Settings

  • 在弹出的面板中找到 Build Tools

  • 选择 Any changes，点击 ok 即可生效

1.5.2 依赖范围

通过设置坐标的依赖范围(scope)，可以设置 对应jar包的作用范围：编译环境、测试环境、运行环境。

如下图所示给 junit 依赖通过 scope 标签指定依赖的作用范围。 那么这个依赖就只能作用在测试环境，其他环境下不能使用。

image-20210726194703845

那么 scope 都可以有哪些取值呢？

依赖范围 编译classpath 测试classpath 运行classpath 例子
compile Y Y Y logback
test - Y - Junit
provided Y Y - servlet-api
runtime - Y Y jdbc驱动
system Y Y - 存储在本地的jar包
  • compile ：作用于编译环境、测试环境、运行环境。
  • test ： 作用于测试环境。典型的就是Junit坐标，以后使用Junit时，都会将scope指定为该值
  • provided ：作用于编译环境、测试环境。我们后面会学习 servlet-api ，在使用它时，必须将 scope 设置为该值，不然运行时就会报错
  • runtime ： 作用于测试环境、运行环境。jdbc驱动一般将 scope 设置为该值，当然不设置也没有任何问题

注意：

  • 如果引入坐标不指定 scope 标签时，默认就是 compile 值。以后大部分jar包都是使用默认值。

1.5.3 查找依赖

  1. 利用中央仓库搜索的依赖坐标，以常见的logback-classic为例。

image.png

  1. 利用IDEA工具搜索依赖，以常见的logback-classic为例。

image.png

  1. 熟练上手maven后，快速导入依赖，以常见的logback-classic为例。

image.png

1.5.4 依赖传递

我们上面在pom.xml中配置了一项依赖，就是spring-context，但是我们通过右侧的maven面板可以看到，其实引入进来的依赖，并不是这一项，有非常多的依赖，都引入进来了。我们可以看到如下图所示：

image.png

为什么会出现这样的现象呢? 那这里呢，就涉及到maven中非常重要的一个特性，那就是Maven中的依赖传递。

所谓maven的依赖传递，指的就是如果在maven项目中，A 依赖了B，B依赖了C，C依赖了D，那么在A项目中，也会有C、D依赖，因为依赖会传递。

那如果，传递下来的依赖，在项目开发中，我们确实不需要，此时，我们可以通过Maven中的排除依赖功能，来将这个依赖排除掉。

1.5.5 排除依赖

image.png

  • 排除依赖：指主动断开依赖的资源，被排除的资源无需指定版本。
  • 配置形式如下：
1
2
3
4
5
6
7
8
9
10
11
12
13
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context</artifactId>
    <version>6.1.4</version>

    <!--排除依赖, 主动断开依赖的资源-->
    <exclusions>
        <exclusion>
            <groupId>io.micrometer</groupId>
            <artifactId>micrometer-observation</artifactId>
        </exclusion>
    </exclusions>
</dependency>

依赖排除示例：

  1. 默认通过maven的依赖传递，传递下来了 micrometer-observation 的依赖。

image.png

  1. 加入排除依赖的配置之后，该依赖就被排除掉了。

image.png

2. 单元测试

2.1 介绍

测试： 是一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。

阶段划分： 单元测试、集成测试、系统测试、验收测试。

image.png

1). 单元测试

  • 介绍：对软件的基本组成单位进行测试，最小测试单位。
  • 目的：检验软件基本组成单位的正确性。
  • 测试人员：开发人员

2). 集成测试

  • 介绍：将已分别通过测试的单元，按设计要求组合成系统或子系统，再进行的测试。
  • 目的：检查单元之间的协作是否正确。
  • 测试人员：开发人员

3). 系统测试

  • 介绍：对已经集成好的软件系统进行彻底的测试。
  • 目的：验证软件系统的正确性、性能是否满足指定的要求。
  • 测试人员：测试人员

4). 验收测试

  • 介绍：交付测试，是针对用户需求、业务流程进行的正式的测试。
  • 目的：验证软件系统是否满足验收标准。
  • 测试人员：客户/需求方

测试方法： 白盒测试、黑盒测试 及 灰盒测试。

image.png

1). 白盒测试

清楚软件内部结构、代码逻辑。
用于验证代码、逻辑正确性。

2). 黑盒测试

不清楚软件内部结构、代码逻辑。
用于验证软件的功能、兼容性、验收测试等方面。

3). 灰盒测试
结合了白盒测试和黑盒测试的特点，既关注软件的内部结构又考虑外部表现（功能）。

image.png

2.2 Junit入门

2.2.1 单元测试

  • 单元测试：就是针对最小的功能单元(方法)，编写测试代码对其正确性进行测试。
  • JUnit：最流行的Java测试框架之一，提供了一些功能，方便程序进行单元测试。

在之前的课程中，我们进行程序的测试 ，都是main方法中进行测试 。如下图所示：

image.png

通过main方法是可以进行测试的，可以测试程序是否正常运行。但是main方法进行测试时，会存在如下问题：

  1. 测试代码与源代码未分开，难维护。
  2. 一个方法测试失败，影响后面方法。
  3. 无法自动化测试，得到测试报告。

而如果我们使用了JUnit单元测试框架进行测试，将会有以下优势：

  1. 测试代码与源代码分开，便于维护。
  2. 可根据需要进行自动化测试。
  1. 可自动分析测试结果，产出测试报告。

image.png

2.2.2 入门程序

需求：使用JUnit，对UserService中的业务方法进行单元测试，测试其正确性。

  1. 在pom.xml中，引入JUnit的依赖。
1
2
3
4
5
6
7
<!--Junit单元测试依赖-->
<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter</artifactId>
    <version>5.9.1</version>
    <scope>test</scope>
</dependency>
  1. 在test/java目录下，创建测试类，并编写对应的测试方法，并在方法上声明@Test注解。
1
2
3
4
5
@Test
public void testGetAge(){
    Integer age = new UserService().getAge("110002200505091218");
    System.out.println(age);
}
  1. 运行单元测试 (测试通过：绿色；测试失败：红色)。
  • 测试通过显示绿色

image.png

  • 测试失败显示红色

image.png

注意：

  • 测试类的命名规范为：XxxxTest
  • 测试方法的命名规定为：public void xxx(){…}

2.3 断言

JUnit提供了一些辅助方法，用来帮我们确定被测试的方法是否按照预期的效果正常工作，这种方式称为断言。

image.png

示例演示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
package com.itheima;

import org.junit.jupiter.api.*;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.ValueSource;

public class UserServiceTest {
    
    @Test
    public void testGetAge2(){
        Integer age = new UserService().getAge("110002200505091218");
        Assertions.assertNotEquals(18, age, "两个值相等");
//        String s1 = new String("Hello");
//        String s2 = "Hello";
//        Assertions.assertSame(s1, s2, "不是同一个对象引用");
    }

    @Test
    public void testGetGender2(){
        String gender = new UserService().getGender("612429198904201611");
        Assertions.assertEquals("男", gender);
    }
}

测试结果输出：

image.png

2.4 常见注解

在JUnit中还提供了一些注解，还增强其功能，常见的注解有以下几个：

image.png

演示 @BeforeEach，@AfterEach，@BeforeAll，@AfterAll 注解：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
public class UserServiceTest {

    @BeforeEach
    public void testBefore(){
        System.out.println("before...");
    }

    @AfterEach
    public void testAfter(){
        System.out.println("after...");
    }

    @BeforeAll //该方法必须被static修饰
    public static void testBeforeAll(){ 
        System.out.println("before all ...");
    }

    @AfterAll //该方法必须被static修饰
    public static void testAfterAll(){
        System.out.println("after all...");
    }

    @Test
    public void testGetAge(){
        Integer age = new UserService().getAge("110002200505091218");
        System.out.println(age);
    }
    
    @Test
    public void testGetGender(){
        String gender = new UserService().getGender("612429198904201611");
        System.out.println(gender);
    }
 }

输出结果如下：

image.png

演示 @ParameterizedTest ，@ValueSource ，@DisplayName 注解：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
package com.itheima;

import org.junit.jupiter.api.*;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.ValueSource;

@DisplayName("测试-学生业务操作")
public class UserServiceTest {

    @DisplayName("测试-获取年龄")
    @Test
    public void testGetAge(){
        Integer age = new UserService().getAge("110002200505091218");
        System.out.println(age);
    }

    @DisplayName("测试-获取性别")
    @Test
    public void testGetGender(){
        String gender = new UserService().getGender("612429198904201611");
        System.out.println(gender);
    }

    @DisplayName("测试-获取性别3")
    @ParameterizedTest
    @ValueSource(strings = {"612429198904201611","612429198904201631","612429198904201626"})
    public void testGetGender3(String idcard){
        String gender = new UserService().getGender(idcard);
         System.out.println(gender);
    }
}

输出结果如下：

image.png

思考: 在maven项目中，test目录存放单元测试的代码，是否可以在main目录中编写单元测试呢 ？ 可以，但是不规范

image.png

2.5 依赖范围

依赖的jar包，默认情况下，可以在任何地方使用，在main目录下，可以使用；在test目录下，也可以使用。

在maven中，如果希望限制依赖的使用范围，可以通过 <scope>…</scope> 设置其作用范围。

image.png

作用范围：

  • 主程序范围有效。（main文件夹范围内）
  • 测试程序范围有效。（test文件夹范围内）
  • 是否参与打包运行。（package指令范围内）

可以在pom.xml中配置 <scope></scope> 属性来控制依赖范围。

image.png

如果对Junit单元测试的依赖，设置了scope为 test，就代表，该依赖，只是在测试程序中可以使用，在主程序中是无法使用的。所以我们会看到如下现象：

image.png

如上图所示，给junit依赖通过scope标签指定依赖的作用范围。 那么这个依赖就只能作用在测试环境，其他环境下不能使用。

scope的取值常见的如下：

image.png

Maven常见问题

image.png

  • 问题现象： Maven项目中添加的依赖，未正确下载，造成右侧Maven面板中的依赖报红，再次reload重新加载也不会再下载。
  • 产生原因： 由于网络原因，依赖没有下载完整导致的，在maven仓库中生成了xxx.lastUpdated文件，该文件不删除，不会再重新下载。

image.png

解决方案：

  1. 根据maven依赖的坐标，找到仓库中对应的 xxx.lastUpdated 文件，删除，删除之后重新加载项目即可。
  2. 通过命令 (del /s \*.lastUpdated) 批量递归删除指定目录下的 xxx.lastUpdated 文件，删除之后重新加载项目即可。
  3. 重新加载依赖，依赖下载了之后，maven面板可能还会报红，此时可以关闭IDEA，重新打开IDEA加载此项目即可。

为了使大家能够方便的解决这个问题，大家可以将资料中提供的 del.bat 批处理脚本，拷贝到 maven 的安装目录下。 双击这个文件，就可以递归删除该目录下所有的 xxx.lastUpdated 文件。 放置目录如下所示：

image.png

  • 附件（上述提到的del.bat批处理文件， 也可以直接点此下载）：

Maven高级

Web开发讲解完毕之后，我们再来学习Maven高级。其实在前面的课程当中，我们已经学习了Maven。

我们讲到 Maven 是一款构建和管理 Java 项目的工具。经过前面 10 多天 web 开发的学习，相信大家对于 Maven 这款工具的基本使用应该没什么问题了。我们掌握了 Maven 工具的基本使用之后，其实对于一些简单的项目的构建及管理基本上就没什么问题了。

但是如果我们需要开发一些中大型的项目，此时仅凭我们前面所学习的 Maven 的基础知识就比较难以应对了。所以我们接下来还需要学习 Maven 提供的一些高级的功能，这些功能在构建和管理 Java 项目的时候用的也是非常多的。

Maven高级内容包括:

  • 分模块设计与开发
  • 继承与聚合

1. 分模块设计与开发

1.1 介绍

所谓分模块设计，顾名思义指的就是我们在设计一个 Java 项目的时候，将一个 Java 项目拆分成多个模块进行开发。

1). 未分模块设计的问题

image-20230113090241470

如果项目不分模块，也就意味着所有的业务代码是不是都写在这一个 Java 项目当中。随着这个项目的业务扩张，项目当中的业务功能可能会越来越多。

假如我们开发的是一个大型的电商项目，里面可能就包括了商品模块的功能、搜索模块的功能、购物车模块、订单模块、用户中心等等。这些所有的业务代码我们都在一个 Java 项目当中编写。

此时大家可以试想一下，假如我们开发的是一个大型的电商网站，这个项目组至少几十号甚至几百号开发人员，这些开发人员全部操作这一个 Java 项目。此时大家就会发现我们项目管理和维护起来将会非常的困难。而且大家再来看，假如在我们的项目当中，我们自己定义了一些通用的工具类以及通用的组件，而公司还有其他的项目组，其他项目组也想使用我们所封装的这些组件和工具类，其实是非常不方便的。因为 Java 项目当中包含了当前项目的所有业务代码，所以就造成了这里面所封装的一些组件会难以复用。

总结起来，主要两点问题：不方便项目的维护和管理、项目中的通用组件难以复用。

2). 分模块设计

分模块设计我们在进行项目设计阶段，就可以将一个大的项目拆分成若干个模块，每一个模块都是独立的。

image-20230113094045299

比如我们可以将商品的相关功能放在商品模块当中，搜索的相关业务功能我都封装在搜索模块当中，还有像购物车模块、订单模块。而为了组件的复用，我们也可以将项目当中的实体类、工具类以及我们定义的通用的组件都单独的抽取到一个模块当中。

如果当前这个模块，比如订单模块需要用到这些实体类以及工具类或者这些通用组件，此时直接在订单模块当中引入工具类的坐标就可以了。这样我们就将一个项目拆分成了若干个模块儿，这就是分模块儿设计。

分模块儿设计之后，大家再来看。我们在进行项目管理的时候，我就可以几个人一组，几个人来负责订单模块儿，另外几个人来负责购物车模块儿，这样更加便于项目的管理以及项目的后期维护。

而且分模块设计之后，如果我们需要用到另外一个模块的功能，我们直接依赖模块就可以了。比如商品模块、搜索模块、购物车订单模块都需要依赖于通用组件当中封装的一些工具类，我只需要引入通用组件的坐标就可以了。

分模块设计就是将项目按照功能/结构拆分成若干个子模块，方便项目的管理维护、拓展，也方便模块键的相互调用、资源共享。

1.2 实践

1.2.1 分析

我们可以看到在这个项目当中，除了我们所开发的部门管理以及员工管理、登录认证等相关业务功能以外，我们是不是也定义了一些实体类，也就是pojo包下存放的一些类，像分页结果的封装类PageBean、 统一响应结果Result，我们还定义了一些通用的工具类，像Jwts、阿里云OSS操作的工具类等等。

如果在当前公司的其他项目组当中，也想使用我们所封装的这些公共的组件，该怎么办？大家可以思考一下。

  • 方案一：直接依赖我们当前项目 tlias-web-management ，但是存在两大缺点：

    • 这个项目当中包含所有的业务功能代码，而想共享的资源，仅仅是pojo下的实体类，以及 utils 下的工具类。如果全部都依赖进来，项目在启动时将会把所有的类都加载进来，会影响性能。
    • 如果直接把这个项目都依赖进来了，那也就意味着我们所有的业务代码都对外公开了，这个是非常不安全的。

  • 方案二：分模块设计

    • 将pojo包下的实体类，抽取到一个maven模块中 tlias-pojo
    • 将utils包下的工具类，抽取到一个maven模块中 tlias-utils
    • 其他的业务代码，放在tlias-web-management这个模块中，在该模块中需要用到实体类pojo、工具类utils，直接引入对应的依赖即可。

    image-20230113095609518

​ 注意：分模块开发需要先针对模块功能进行设计，再进行编码。不会先将工程开发完毕，然后进行拆分。

​ PS：当前我们是为了演示分模块开发，所以是基于我们前面开发的案例项目进行拆分的，实际中都是分模块设计，然后再开发的。

1.2.2 实现

思路我们分析完毕，接下来，我们就根据我们分析的思路，按照如下模块进行拆分：

1. 创建maven模块 tlias-pojo，存放实体类

A. 创建一个正常的Maven模块，模块名tlias-pojo

B. 然后在tlias-pojo中创建一个包 com.zhisheng.pojo (和原来案例项目中的pojo包名一致)

C. 将原来案例项目 tlias-web-management 中的pojo包下的实体类，复制到tlias-pojo模块中

D. 在 tlias-pojo 模块的pom.xml文件中引入依赖

1
2
3
4
5
6
7
<dependencies>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>1.18.24</version>
    </dependency>
</dependencies>

E. 删除原有案例项目tlias-web-management的pojo包【直接删除不要犹豫，我们已经将该模块拆分出去了】，然后在pom.xml中引入 tlias-pojo的依赖

1
2
3
4
5
<dependency>
    <groupId>com.zhisheng</groupId>
    <artifactId>tlias-pojo</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>

2. 创建Maven模块 tlias-utils，存放相关工具类

A. 创建一个正常的Maven模块，模块名tlias-utils

B. 然后在 tlias-utils 中创建一个包 com.zhisheng.utils (和原来案例项目中的utils包名一致)

C. 将原来案例项目 tlias-web-management 中的utils包下的实体类，复制到tlias-utils模块中

D. 在 tlias-utils 模块的pom.xml文件中引入依赖

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
<dependencies>
    <!--JWT令牌-->
    <dependency>
        <groupId>io.jsonwebtoken</groupId>
        <artifactId>jjwt</artifactId>
        <version>0.9.1</version>
    </dependency>

    <!--阿里云OSS-->
    <dependency>
        <groupId>com.aliyun.oss</groupId>
        <artifactId>aliyun-sdk-oss</artifactId>
        <version>3.15.1</version>
    </dependency>
    <dependency>
        <groupId>javax.xml.bind</groupId>
        <artifactId>jaxb-api</artifactId>
        <version>2.3.1</version>
    </dependency>
    <dependency>
        <groupId>javax.activation</groupId>
        <artifactId>activation</artifactId>
        <version>1.1.1</version>
    </dependency>
    <!-- no more than 2.3.3-->
    <dependency>
        <groupId>org.glassfish.jaxb</groupId>
        <artifactId>jaxb-runtime</artifactId>
        <version>2.3.3</version>
    </dependency>

    <!--WEB开发-->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <version>2.7.5</version>
    </dependency>

    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>1.18.24</version>
    </dependency>
</dependencies>

E. 删除原有案例项目tlias-web-management的utils包【直接删除不要犹豫，我们已经将该模块拆分出去了】，然后在pom.xml中引入 tlias-utils的依赖

1
2
3
4
5
<dependency>
    <groupId>com.zhisheng</groupId>
    <artifactId>tlias-utils</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>

到此呢，就已经完成了模块的拆分，拆分出了 tlias-pojo、tlias-utils、tlias-web-management ，如果其他项目中需要用到 pojo，或者 utils工具类，就可以直接引入依赖。

1.3 总结

1). 什么是分模块设计：将项目按照功能拆分成若干个子模块

2). 为什么要分模块设计：方便项目的管理维护、扩展，也方便模块间的相互调用，资源共享

3). 注意事项：分模块设计需要先针对模块功能进行设计，再进行编码。不会先将工程开发完毕，然后进行拆分

2. 继承与聚合

在案例项目分模块开发之后啊，我们会看到tlias-pojo、tlias-utils、tlias-web-management中都引入了一个依赖 lombok 的依赖。我们在三个模块中分别配置了一次。

image-20230113103714055

如果是做一个大型的项目，这三个模块当中重复的依赖可能会很多很多。如果每一个 Maven 模块里面，我们都来单独的配置一次，功能虽然能实现，但是配置是比较繁琐的。

而接下来我们要讲解的 Maven 的继承用来解决这问题的。

2.1 继承

我们可以再创建一个父工程 tlias-parent ，然后让上述的三个模块 tlias-pojo、tlias-utils、tlias-web-management 都来继承这个父工程 。 然后再将各个模块中都共有的依赖，都提取到父工程 tlias-parent中进行配置，只要子工程继承了父工程，依赖它也会继承下来，这样就无需在各个子工程中进行配置了。

image-20230113111557714

  • 概念：继承描述的是两个工程间的关系，与java中的继承相似，子工程可以继承父工程中的配置信息，常见于依赖关系的继承。

  • 作用：简化依赖配置、统一管理依赖

  • 实现：

    1
    2
    3
    4
    5
    6
    <parent>
        <groupId>...</groupId>
        <artifactId>...</artifactId>
        <version>...</version>
        <relativePath>....</relativePath>
    </parent>

这是我们在这里先介绍一下什么是继承以及继承的作用，以及在 maven 当中如何来实现这层继承关系。接下来我们就来创建这样一个 parent 父工程，我们就可以将各个子工程当中共有的这部分依赖统一的定义在父工程 parent 当中，从而来简化子工程的依赖配置。接下来我们来看一下具体的操作步骤。

我们在这里先介绍一下什么是继承以及继承的作用，以及在 maven 当中如何来实现这层继承关系。接下来我们就来创建这样一个 parent 父工程，我们就可以将各个子工程当中共有的这部分依赖，统一的定义在父工程 parent 当中，从而来简化子工程的依赖配置。

2.1.1 继承关系

2.1.1.1 思路分析

我们当前的项目 tlias-web-management，还稍微有一点特殊，因为是一个springboot项目，而所有的springboot项目都有一个统一的父工程，就是spring-boot-starter-parent。 与java语言类似，Maven不支持多继承，一个maven项目只能继承一个父工程，如果继承了spring-boot-starter-parent，就没法继承我们自己定义的父工程 tlias-parent了。

那我们怎么来解决这个问题呢？

那此时，大家可以想一下，Java虽然不支持多继承，但是可以支持多重继承，比如：A 继承 B， B 继承C。 那在Maven中也是支持多重继承的，所以呢，我们就可以让 我们自己创建的三个模块，都继承tlias-parent，而tlias-parent 再继承 spring-boot-starter-parent，就可以了。 具体结构如下：

image-20230113113004727

2.1.1.2 实现

1). 创建maven模块 tlias-parent ，该工程为父工程，设置打包方式pom(默认jar)。

父工程tlias-parent的pom.xml文件配置如下：

1
2
3
4
5
6
7
8
9
10
11
<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.7.5</version>
    <relativePath/> <!-- lookup parent from repository -->
</parent>

<groupId>com.zhisheng</groupId>
<artifactId>tlias-parent</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>pom</packaging>

Maven打包方式：

  • jar：普通模块打包，springboot项目基本都是jar包（内嵌tomcat运行）
  • war：普通web程序打包，需要部署在外部的tomcat服务器中运行
  • pom：父工程或聚合工程，该模块不写代码，仅进行依赖管理

2). 在子工程的pom.xml文件中，配置继承关系。

1
2
3
4
5
6
7
8
9
<parent>
    <groupId>com.zhisheng</groupId>
    <artifactId>tlias-parent</artifactId>
    <version>1.0-SNAPSHOT</version>
    <relativePath>../tlias-parent/pom.xml</relativePath>
</parent>

<artifactId>tlias-utils</artifactId>
<version>1.0-SNAPSHOT</version>

这里是以 tlias-utils 为例，指定了其父工程。其他的模块，都是相同的配置方式。

注意：

  • 在子工程中，配置了继承关系之后，坐标中的groupId是可以省略的，因为会自动继承父工程的 。
  • relativePath指定父工程的pom文件的相对位置（如果不指定，将从本地仓库/远程仓库查找该工程）。
    • ../ 代表的上一级目录

3). 在父工程中配置各个工程共有的依赖（子工程会自动继承父工程的依赖）。

1
2
3
4
5
6
7
<dependencies>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>1.18.24</version>
    </dependency>
</dependencies>

此时，我们已经将各个子工程中共有的依赖（lombok），都定义在了父工程中，子工程中的这一项依赖，就可以直接删除了。删除之后，我们会看到父工程中配置的依赖 lombok，子工程直接继承下来了。

image-20230113120408661

工程结构说明：

  • 我们当前的项目结构为：

    image-20230113120636912

    因为我们是项目开发完毕之后，给大家基于现有项目拆分的各个模块，tlias-web-management已经存在了，然后再创建各个模块与父工程，所以父工程与模块之间是平级的。

  • 而实际项目中，可能还会见到下面的工程结构：

    image-20230113120728680

    而在真实的企业开发中，都是先设计好模块之后，再开始创建模块，开发项目。 那此时呢，一般都会先创建父工程 tlias-parent，然后将创建的各个子模块，都放在父工程parent下面。 这样层级结构会更加清晰一些。

    ​

    PS：上面两种工程结构，都是可以正常使用的，没有一点问题。 只不过，第二种结构，看起来，父子工程结构更加清晰、更加直观。

2.1.2 版本锁定

2.1.2.1 场景

如果项目中各个模块中都公共的这部分依赖，我们可以直接定义在父工程中，从而简化子工程的配置。 然而在项目开发中，还有一部分依赖，并不是各个模块都共有的，可能只是其中的一小部分模块中使用到了这个依赖。

比如：在tlias-web-management、tlias-web-system、tlias-web-report这三个子工程中，都使用到了jwt的依赖。 但是 tlias-pojo、tlias-utils中并不需要这个依赖，那此时，这个依赖，我们不会直接配置在父工程 tlias-parent中，而是哪个模块需要，就在哪个模块中配置。

而由于是一个项目中的多个模块，那多个模块中，我们要使用的同一个依赖的版本要一致，这样便于项目依赖的统一管理。比如：这个jwt依赖，我们都使用的是 0.9.1 这个版本。

image-20230113122213954

那假如说，我们项目要升级，要使用到jwt最新版本 0.9.2 中的一个新功能，那此时需要将依赖的版本升级到0.9.2，那此时该怎么做呢 ？

第一步：去找当前项目中所有的模块的pom.xml配置文件，看哪些模块用到了jwt的依赖。

第二步：找到这个依赖之后，将其版本version，更换为 0.9.2。

问题：如果项目拆分的模块比较多，每一次更换版本，我们都得找到这个项目中的每一个模块，一个一个的更改。 很容易就会出现，遗漏掉一个模块，忘记更换版本的情况。

那我们又该如何来解决这个问题，如何来统一管理各个依赖的版本呢？

答案：Maven的版本锁定功能。

2.1.2.2 介绍

在maven中，可以在父工程的pom文件中通过 <dependencyManagement> 来统一管理依赖版本。

父工程：

1
2
3
4
5
6
7
8
9
10
11
<!--统一管理依赖版本-->
<dependencyManagement>
    <dependencies>
        <!--JWT令牌-->
        <dependency>
            <groupId>io.jsonwebtoken</groupId>
            <artifactId>jjwt</artifactId>
            <version>0.9.1</version>
        </dependency>
    </dependencies>
</dependencyManagement>

子工程：

1
2
3
4
5
6
7
<dependencies>
    <!--JWT令牌-->
    <dependency>
        <groupId>io.jsonwebtoken</groupId>
        <artifactId>jjwt</artifactId>
    </dependency>
</dependencies>

注意：

  • 在父工程中所配置的 <dependencyManagement> 只能统一管理依赖版本，并不会将这个依赖直接引入进来。 这点和 <dependencies> 是不同的。

  • 子工程要使用这个依赖，还是需要引入的，只是此时就无需指定 <version> 版本号了，父工程统一管理。变更依赖版本，只需在父工程中统一变更。

2.1.2.3 实现

接下来，我们就可以将tlias-utils模块中单独配置的依赖，将其版本统一交给 tlias-parent 进行统一管理。

具体步骤如下：

1). tlias-parent 中的配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
<!--统一管理依赖版本-->
<dependencyManagement>
    <dependencies>
        <!--JWT令牌-->
        <dependency>
            <groupId>io.jsonwebtoken</groupId>
            <artifactId>jjwt</artifactId>
            <version>0.9.1</version>
        </dependency>

        <!--阿里云OSS-->
        <dependency>
            <groupId>com.aliyun.oss</groupId>
            <artifactId>aliyun-sdk-oss</artifactId>
            <version>3.15.1</version>
        </dependency>
        <dependency>
            <groupId>javax.xml.bind</groupId>
            <artifactId>jaxb-api</artifactId>
            <version>2.3.1</version>
        </dependency>
        <dependency>
            <groupId>javax.activation</groupId>
            <artifactId>activation</artifactId>
            <version>1.1.1</version>
        </dependency>
        <!-- no more than 2.3.3-->
        <dependency>
            <groupId>org.glassfish.jaxb</groupId>
            <artifactId>jaxb-runtime</artifactId>
            <version>2.3.3</version>
        </dependency>
    </dependencies>
</dependencyManagement>

2). tlias-utils中的pom.xml配置

如果依赖的版本已经在父工程进行了统一管理，所以在子工程中就无需再配置依赖的版本了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
<dependencies>
    <!--JWT令牌-->
    <dependency>
        <groupId>io.jsonwebtoken</groupId>
        <artifactId>jjwt</artifactId>
    </dependency>

    <!--阿里云OSS-->
    <dependency>
        <groupId>com.aliyun.oss</groupId>
        <artifactId>aliyun-sdk-oss</artifactId>
    </dependency>
    <dependency>
        <groupId>javax.xml.bind</groupId>
        <artifactId>jaxb-api</artifactId>
    </dependency>
    <dependency>
        <groupId>javax.activation</groupId>
        <artifactId>activation</artifactId>
    </dependency>
    <!-- no more than 2.3.3-->
    <dependency>
        <groupId>org.glassfish.jaxb</groupId>
        <artifactId>jaxb-runtime</artifactId>
    </dependency>

    <!--WEB开发-->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
</dependencies>

我们之所以，在springboot项目中很多时候，引入依赖坐标，都不需要指定依赖的版本 <version> ，是因为在父工程 spring-boot-starter-parent中已经通过 <dependencyManagement>对依赖的版本进行了统一的管理维护。

2.1.2.4 属性配置

我们也可以通过自定义属性及属性引用的形式，在父工程中将依赖的版本号进行集中管理维护。 具体语法为：

1). 自定义属性

1
2
3
<properties>
	<lombok.version>1.18.24</lombok.version>
</properties>

2). 引用属性

1
2
3
4
5
<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <version>${lombok.version}</version>
</dependency>

接下来，我们就可以在父工程中，将所有的版本号，都集中管理维护起来。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
<properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>

    <lombok.version>1.18.24</lombok.version>
    <jjwt.version>0.9.1</jjwt.version>
    <aliyun.oss.version>3.15.1</aliyun.oss.version>
    <jaxb.version>2.3.1</jaxb.version>
    <activation.version>1.1.1</activation.version>
    <jaxb.runtime.version>2.3.3</jaxb.runtime.version>
</properties>


<dependencies>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>${lombok.version}</version>
    </dependency>
</dependencies>

<!--统一管理依赖版本-->
<dependencyManagement>
    <dependencies>
        <!--JWT令牌-->
        <dependency>
            <groupId>io.jsonwebtoken</groupId>
            <artifactId>jjwt</artifactId>
            <version>${jjwt.version}</version>
        </dependency>

        <!--阿里云OSS-->
        <dependency>
            <groupId>com.aliyun.oss</groupId>
            <artifactId>aliyun-sdk-oss</artifactId>
            <version>${aliyun.oss.version}</version>
        </dependency>
        <dependency>
            <groupId>javax.xml.bind</groupId>
            <artifactId>jaxb-api</artifactId>
            <version>${jaxb.version}</version>
        </dependency>
        <dependency>
            <groupId>javax.activation</groupId>
            <artifactId>activation</artifactId>
            <version>${activation.version}</version>
        </dependency>
        <!-- no more than 2.3.3-->
        <dependency>
            <groupId>org.glassfish.jaxb</groupId>
            <artifactId>jaxb-runtime</artifactId>
            <version>${jaxb.runtime.version}</version>
        </dependency>
    </dependencies>
</dependencyManagement>

版本集中管理之后，我们要想修改依赖的版本，就只需要在父工程中自定义属性的位置，修改对应的属性值即可。

面试题：<dependencyManagement> 与 <dependencies> 的区别是什么?

  • <dependencies> 是直接依赖，在父工程配置了依赖，子工程会直接继承下来。
  • <dependencyManagement> 是统一管理依赖版本，不会直接依赖，还需要在子工程中引入所需依赖(无需指定版本)

2.2 聚合

分模块设计与开发之后啊，我们的项目被拆分为多个模块，而模块之间的关系，可能错综复杂。 那就比如我们当前的案例项目，结构如下（相对还是比较简单的）：

image-20230113142520463

此时，tlias-web-management 模块的父工程是 tlias-parent，该模块又依赖了tlias-pojo、tlias-utils模块。 那此时，我们要想将 tlias-web-management 模块打包，是比较繁琐的。因为在进行项目打包时，maven会从本地仓库中来查找tlias-parent父工程，以及它所依赖的模块tlias-pojo、tlias-utils，而本地仓库目前是没有这几个依赖的。

所以，我们再打包tlias-web-management 模块前，需要将 tlias-parent、tlias-pojo、tlias-utils分别执行install生命周期安装到maven的本地仓库，然后再针对于 tlias-web-management 模块执行package进行打包操作。

那此时，大家试想一下，如果开发一个大型项目，拆分的模块很多，模块之间的依赖关系错综复杂，那此时要进行项目的打包、安装操作，是非常繁琐的。 而我们接下来，要讲解的maven的聚合就是来解决这个问题的，通过maven的聚合就可以轻松实现项目的一键构建（清理、编译、测试、打包、安装等）。

2.2.1 介绍

image-20230113151533948
  • **聚合：**将多个模块组织成一个整体，同时进行项目的构建。
  • **聚合工程：**一个不具有业务功能的“空”工程（有且仅有一个pom文件） 【PS：一般来说，继承关系中的父工程与聚合关系中的聚合工程是同一个】
  • **作用：**快速构建项目（无需根据依赖关系手动构建，直接在聚合工程上构建即可）

2.2.2 实现

在maven中，我们可以在聚合工程中通过 <moudules> 设置当前聚合工程所包含的子模块的名称。我们可以在 tlias-parent中，添加如下配置，来指定当前聚合工程，需要聚合的模块：

1
2
3
4
5
6
<!--聚合其他模块-->
<modules>
    <module>../tlias-pojo</module>
    <module>../tlias-utils</module>
    <module>../tlias-web-management</module>
</modules>

那此时，我们要进行编译、打包、安装操作，就无需在每一个模块上操作了。只需要在聚合工程上，统一进行操作就可以了。

**测试：**执行在聚合工程 tlias-parent 中执行 package 打包指令

image-20230113153347978

那 tlias-parent 中所聚合的其他模块全部都会执行 package 指令，这就是通过聚合实现项目的一键构建（一键清理clean、一键编译compile、一键测试test、一键打包package、一键安装install等）。

2.3 继承与聚合对比

  • 作用

    • 聚合用于快速构建项目

    • 继承用于简化依赖配置、统一管理依赖

  • 相同点：

    • 聚合与继承的pom.xml文件打包方式均为pom，通常将两种关系制作到同一个pom文件中

    • 聚合与继承均属于设计型模块，并无实际的模块内容

  • 不同点：

    • 聚合是在聚合工程中配置关系，聚合可以感知到参与聚合的模块有哪些

    • 继承是在子模块中配置关系，父模块无法感知哪些子模块继承了自己