Maven认识与学习

1. Maven介绍

1.2 初识Maven

1.2.1 什么是Maven

Maven是Apache旗下的一个开源项目，是一款用于管理和构建java项目的工具。

官网：Maven – Welcome to Apache Maven

Apache 软件基金会，成立于1999年7月，是目前世界上最大的最受欢迎的开源软件基金会，也是一个专门为支持开源项目而生的非盈利性组织。

开源项目：Welcome to The Apache Software Foundation!

1.2.2 Maven的作用

使用Maven能够做什么呢？

依赖管理
统一项目结构
项目构建

依赖管理：

方便快捷的管理项目依赖的资源(jar包)，避免版本冲突问题

当使用maven进行项目依赖(jar包)管理，则很方便的可以解决这个问题。我们只需要在maven项目的pom.xml文件中，添加一段如下图所示的配置即可实现。

统一项目结构 :

提供标准、统一的项目结构

在项目开发中，当你使用不同的开发工具 (如：Eclipse、Idea)，创建项目工程时：

若我们创建的是一个maven工程，是可以帮我们自动生成统一、标准的项目目录结构：

具体的统一结构如下：

目录说明：

src/main/java: java源代码目录

src/main/resources: 配置文件信息

src/test/java: 测试代码

src/test/resources: 测试配置文件信息

项目构建 :

maven提供了标准的、跨平台(Linux、Windows、MacOS) 的自动化项目构建方式

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

综上所述，可以得到一个结论：Maven是一款管理和构建java项目的工具

2. Maven概述

2.1 Maven介绍

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

官网：Maven – Welcome to Apache Maven

Maven的作用：

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

2.2 Maven模型

项目对象模型 (Project Object Model)
依赖管理模型(Dependency)
构建生命周期/阶段(Build lifecycle & phases)

1). 构建生命周期/阶段(Build lifecycle & phases)

以上图中紫色框起来的部分，就是用来完成标准化构建流程。当我们需要编译，Maven提供了一个编译插件供我们使用；当我们需要打包，Maven就提供了一个打包插件供我们使用等。

2). 项目对象模型 (Project Object Model)

以上图中紫色框起来的部分属于项目对象模型，就是将我们自己的项目抽象成一个对象模型，有自己专属的坐标，如下图所示是一个Maven项目：

坐标，就是资源(jar包)的唯一标识，通过坐标可以定位到所需资源(jar包)位置

3). 依赖管理模型(Dependency)

以上图中紫色框起来的部分属于依赖管理模型，是使用坐标来描述当前项目依赖哪些第三方jar包

之前我们项目中需要jar包时，直接就把jar包复制到项目下的lib目录，而现在书写在pom.xml文件中的坐标又是怎么能找到所要的jar包文件的呢？

答案：Maven仓库

2.3 Maven仓库

仓库：用于存储资源，管理各种jar包

仓库的本质就是一个目录(文件夹)，这个目录被用来存储开发中所有依赖(就是jar包)和插件

Maven仓库分为：

本地仓库：自己计算机上的一个目录(用来存储jar包)
中央仓库：由Maven团队维护的全球唯一的。仓库地址：Central Repository:
远程仓库(私服)：一般由公司团队搭建的私有仓库

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

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

如果还可以搭建远程仓库(私服)，将来jar包的查找顺序则变为：本地仓库 --> 远程仓库--> 中央仓库

2.4 Maven安装

认识了Maven后，我们就要开始使用Maven了，那么首先我们要进行Maven的下载与安装。

2.4.1 下载

下载地址：Maven – Download Apache Maven

2.4.2 安装步骤

Maven安装配置步骤：

解压安装
配置仓库
配置Maven环境变量

1、解压 apache-maven-3.6.1-bin.zip（解压即安装）

建议解压到没有中文、特殊字符的路径下。如课程中解压到 E:\develop 下。

解压缩后的目录结构如下：

bin目录：存放的是可执行命令。（mvn 命令重点关注）
conf目录：存放Maven的配置文件。（settings.xml配置文件后期需要修改）
lib目录：存放Maven依赖的jar包。（Maven也是使用java开发的，所以它也依赖其他的jar包）

2、配置本地仓库

2.1、在自己计算机上新一个目录（本地仓库，用来存储jar包）

2.2、进入到conf目录下修改settings.xml配置文件

1). 使用超级记事本软件，打开settings.xml文件，定位到53行

2). 复制<localRepository>标签，粘贴到注释的外面（55行）

3). 复制之前新建的用来存储jar包的路径，替换掉<localRepository>标签体内容

3、配置阿里云私服

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

进入到conf目录下修改settings.xml配置文件：

1). 使用超级记事本软件，打开settings.xml文件，定位到160行左右

2). 在<mirrors>标签下为其添加子标签<mirror>，内容如下：

<mirror>  <id>alimaven</id>  <name>aliyun maven</name>  <url>http://maven.aliyun.com/nexus/content/groups/public/</url><mirrorOf>central</mirrorOf>          
</mirror>

注意配置的位置，在<mirrors> ... </mirrors> 中间添加配置。如下图所示：

==注: 只可配置一个<mirror>(另一个要注释!) ，不然两个可能发生冲突，导致jar包无法下载!!!!!!!==

4、配置环境变量

Maven环境变量的配置类似于JDK环境变量配置一样

1). 在系统变量处新建一个变量MAVEN_HOME

MAVEN_HOME环境变量的值，设置为maven的解压安装目录

2). 在Path中进行配置

PATH环境变量的值，设置为：%MAVEN_HOME%\bin

3). 打开DOS命令提示符进行验证，出现如图所示表示安装成功

mvn -v

3. IDEA集成Maven

我们要想在IDEA中使用Maven进行项目构建，就需要在IDEA中集成Maven

3.1 配置Maven环境

3.1.1 当前工程设置

1、选择 IDEA中 File => Settings => Build,Execution,Deployment => Build Tools => Maven

2、设置IDEA使用本地安装的Maven，并修改配置文件及本地仓库路径

Maven home path ：指定当前Maven的安装目录

User settings file ：指定当前Maven的settings.xml配置文件的存放路径

Local repository ：指定Maven的本地仓库的路径 (如果指定了settings.xml, 这个目录会自动读取出来, 可以不用手动指定)

3、配置工程的编译版本为21

Maven默认使用的编译版本为5（版本过低）

上述配置的maven环境，只是针对于当前工程的，如果我们再创建一个project，又恢复成默认的配置了。要解决这个问题，我们就需要配置全局的maven环境。

3.1.2 全局设置

1、进入到IDEA欢迎页面

选择 IDEA中 File => close project

2、打开 All settings , 选择 Build,Execution,Deployment => Build Tools => Maven

3、配置工程的编译版本为21

这里所设置的maven的环境信息，并未指定任何一个project，此时设置的信息就属于全局配置信息。以后，我们再创建project，默认就是使用我们全局配置的信息。

3.2 Maven项目

3.2.1 创建Maven项目

1、创建一个空项目

2、创建模块，选择Maven，点击Next

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

4、在Maven工程下，创建HelloWorld类

Maven项目的目录结构:

maven-project01

        |--- src (源代码目录和测试代码目录)

                |--- main (源代码目录)

                        |--- java (源代码java文件目录)

                        |--- resources (源代码配置文件目录)

                |--- test (测试代码目录)

                        |--- java (测试代码java目录)

                        |--- resources (测试代码配置文件目录)

        |--- target (编译、打包生成文件存放目录)

5、编写 HelloWorld，并运行

public class HelloWorld {public static void main(String[] args) {System.out.println("Hello Maven ...");}
}

3.2.2 POM配置详解

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

使用pom.xml文件来实现

pom.xml文件：

<?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_project1</artifactId><version>1.0-SNAPSHOT</version><!-- 打包方式 --><packaging>jar</packaging></project>

pom文件详解：

<project> ：pom文件的根标签，表示当前maven项目
<modelVersion> ：声明项目描述遵循哪一个POM模型版本
- 虽然模型本身的版本很少改变，但它仍然是必不可少的。目前POM模型版本是4.0.0
坐标：<groupId>、<artifactId>、<version>
- 定位项目在本地仓库中的位置，由以上三个标签组成一个坐标
<packaging> ：maven项目的打包方式，通常设置为jar或war（默认值：jar）

3.2.3 Maven坐标详解

什么是坐标？

Maven中的坐标是==资源的唯一标识== , 通过该坐标可以唯一定位资源位置
使用坐标来定义项目或引入项目中需要的依赖

Maven坐标主要组成

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

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

注意：

上面所说的资源可以是插件、依赖、当前项目。

我们的项目如果被其他的项目依赖时，也是需要坐标来引入的。

3.3 导入Maven项目

方式1：使用Maven面板，快速导入项目

打开IDEA，选择右侧Maven面板，点击 + 号，选中对应项目的pom.xml文件，双击即可

说明：如果没有Maven面板，选择 View => Appearance => Tool Window Bars

方式2：使用idea导入模块项目

File => Project Structure => Modules => + => Import Module

找到要导入工程的pom.xml

4. 依赖管理

4.1 依赖配置

依赖：指当前项目运行所需要的jar包。一个项目中可以引入多个依赖：

例如：在当前工程中，我们需要用到logback来记录日志，此时就可以在maven工程的pom.xml文件中，引入logback的依赖。具体步骤如下：

在pom.xml中编写<dependencies>标签
在<dependencies>标签中使用<dependency>引入坐标
定义坐标的 groupId、artifactId、version

<dependencies><!-- 第1个依赖 : logback --><dependency><groupId>ch.qos.logback</groupId><artifactId>logback-classic</artifactId><version>1.2.11</version></dependency><!-- 第2个依赖 : junit --><dependency><groupId>junit</groupId><artifactId>junit</artifactId><version>4.12</version></dependency>
</dependencies>

4.点击刷新按钮，引入最新加入的坐标

刷新依赖：保证每一次引入新的依赖，或者修改现有的依赖配置，都可以加入最新的坐标

注意事项：

如果引入的依赖，在本地仓库中不存在，将会连接远程仓库 / 中央仓库，然后下载依赖（这个过程会比较耗时，耐心等待）

如果不知道依赖的坐标信息，可以到mvn的中央仓库（https://mvnrepository.com/）中搜索

添加依赖的几种方式：

利用中央仓库搜索的依赖坐标

利用IDEA工具搜索依赖

熟练上手maven后，快速导入依赖

4.2 依赖传递

4.2.1 依赖具有传递性

早期我们没有使用maven时，向项目中添加依赖的jar包，需要把所有的jar包都复制到项目工程下。如下图所示，需要logback-classic时，由于logback-classic又依赖了logback-core和slf4j，所以必须把这3个jar包全部复制到项目工程下

我们现在使用了maven，当项目中需要使用logback-classic时，只需要在pom.xml配置文件中，添加logback-classic的依赖坐标即可。

在pom.xml文件中只添加了logback-classic依赖，但由于maven的依赖具有传递性，所以会自动把所依赖的其他jar包也一起导入。

依赖传递可以分为：

直接依赖：在当前项目中通过依赖配置建立的依赖关系
间接依赖：被依赖的资源如果依赖其他资源，当前项目间接依赖其他资源

比如以上图中：

projectA依赖了projectB。对于projectA 来说，projectB 就是直接依赖。
而projectB依赖了projectC及其他jar包。那么此时，在projectA中也会将projectC的依赖传递下来。对于projectA 来说，projectC就是间接依赖。

4.2.2 排除依赖

之前我们讲了依赖具有传递性。那么A依赖B，B依赖C，如果A不想将C依赖进来，在maven项目中，我们可以通过排除依赖来实现。

排除依赖：指主动断开依赖的资源。（被排除的资源无需指定版本）

<dependency><groupId>com.itheima</groupId><artifactId>maven-projectB</artifactId><version>1.0-SNAPSHOT</version><!--排除依赖, 主动断开依赖的资源--><exclusions><exclusion><groupId>junit</groupId><artifactId>junit</artifactId></exclusion></exclusions>
</dependency>

依赖排除示例：

maven-projectA依赖了maven-projectB，maven-projectB依赖了Junit。基于依赖的传递性，所以maven-projectA也依赖了Junit

使用排除依赖后

4.3 依赖范围

在项目中导入依赖的jar包后，默认情况下，可以在任何地方使用。

如果希望限制依赖的使用范围，可以通过<scope>标签设置其作用范围。

作用范围：

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

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

scope标签的取值范围：

scope值	主程序	测试程序	打包（运行）	范例
compile（默认）	Y	Y	Y	log4j
test	-	Y	-	junit
provided	Y	Y	-	servlet-api
runtime	-	Y	Y	jdbc驱动

4.4 生命周期

4.4.1 介绍

Maven的生命周期就是为了对所有的构建过程进行抽象和统一。描述了一次项目构建，经历哪些阶段。

在Maven出现之前，项目构建的生命周期就已经存在，软件开发人员每天都在对项目进行清理，编译，测试及部署。虽然大家都在不停地做构建工作，但公司和公司间、项目和项目间，往往使用不同的方式做类似的工作。

Maven从大量项目和构建工具中学习和反思，然后总结了一套高度完美的，易扩展的项目构建生命周期。这个生命周期包含了项目的清理，初始化，编译，测试，打包，集成测试，验证，部署和站点生成等几乎所有构建步骤。

Maven对项目构建的生命周期划分为3套（相互独立）：

clean：清理工作。
default：核心工作。如：编译、测试、打包、安装、部署等。
site：生成报告、发布站点等。

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

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

• clean：移除上一次构建生成的文件

• compile：编译项目源代码

• test：使用合适的单元测试框架运行测试(junit)

• package：将编译后的文件打包，如：jar、war等

• install：安装项目到本地仓库

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

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

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

我们需要关注的就是：clean --> compile --> test --> package --> install

说明：在同一套生命周期中，我们在执行后面的生命周期时，前面的生命周期都会执行。

思考：当运行package生命周期时，clean、compile生命周期会不会运行？

clean不会运行，compile会运行。因为compile与package属于同一套生命周期，而clean与package不属于同一套生命周期。

4.4.2 执行

在日常开发中，当我们要执行指定的生命周期时，有两种执行方式：

在idea工具右侧的maven工具栏中，选择对应的生命周期，双击执行
在DOS命令行中，通过maven命令执行

方式一：在idea中执行生命周期

选择对应的生命周期，双击执行

compile：

test：

package：

install：

clean：

方式二：在命令行中执行生命周期

进入到DOS命令行

5. 附录

5.1 更新依赖索引

有时候给idea配置完maven仓库信息后，在idea中依然搜索不到仓库中的jar包。这是因为仓库中的jar包索引尚未更新到idea中。这个时候我们就需要更新idea中maven的索引了，具体做法如下：

打开设置----搜索maven----Repositories----选中本地仓库-----点击Update

5.2 清理maven仓库

初始情况下，我们的本地仓库是没有任何jar包的，此时会从私服去下载（如果没有配置，就直接从中央仓库去下载），可能由于网络的原因，jar包下载不完全，这些不完整的jar包都是以lastUpdated结尾。此时，maven不会再重新帮你下载，需要你删除这些以lastUpdated结尾的文件，然后maven才会再次自动下载这些jar包。

如果本地仓库中有很多这样的以lastUpadted结尾的文件，可以定义一个批处理文件，在其中编写如下脚本来删除：

set REPOSITORY_PATH=E:\develop\apache-maven-3.6.1\mvn_repo
rem 正在搜索...

del /s /q %REPOSITORY_PATH%\*.lastUpdated

rem 搜索完毕
pause

操作步骤如下：

1). 定义批处理文件del_lastUpdated.bat (直接创建一个文本文件，命名为del_lastUpdated，后缀名直接改为bat即可 )

2). 在上面的bat文件上右键---》编辑 。修改文件：

修改完毕后，双击运行即可删除maven仓库中的残留文件。

6. 分模块设计与开发

6.1 介绍

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

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

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

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

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

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

2). 分模块设计

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

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

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

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

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

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

6.2 实践

6.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，直接引入对应的依赖即可。

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

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

6.2.2 实现

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

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

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

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

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

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

<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的依赖

<dependency><groupId>com.itheima</groupId><artifactId>tlias-pojo</artifactId><version>1.0-SNAPSHOT</version>
</dependency>

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

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

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

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

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

<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的依赖

<dependency><groupId>com.itheima</groupId><artifactId>tlias-utils</artifactId><version>1.0-SNAPSHOT</version>
</dependency>

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

6.3 总结

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

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

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

7. 继承与聚合

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

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

7.1 继承

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

概念：继承描述的是两个工程间的关系，与java中的继承相似，子工程可以继承父工程中的配置信息，常见于依赖关系的继承。
作用：简化依赖配置、统一管理依赖

实现：

<parent><groupId>...</groupId><artifactId>...</artifactId><version>...</version><relativePath>....</relativePath>
</parent>

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

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

7.1.1 继承关系

7.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，就可以了。具体结构如下：

7.1.1.2 实现

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

工程结构如下：

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

<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.itheima</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文件中，配置继承关系。

<parent><groupId>com.itheima</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). 在父工程中配置各个工程共有的依赖（子工程会自动继承父工程的依赖）。

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

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

工程结构说明：

我们当前的项目结构为：

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

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

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

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

7.1.2 版本锁定

7.1.2.1 场景

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

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

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

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

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

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

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

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

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

7.1.2.2 介绍

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

父工程：

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

子工程：

<dependencies><!--JWT令牌--><dependency><groupId>io.jsonwebtoken</groupId><artifactId>jjwt</artifactId></dependency>
</dependencies>

注意：

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

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

7.1.2.3 实现

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

具体步骤如下：

1). tlias-parent 中的配置

<!--统一管理依赖版本-->
<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配置

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

<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>对依赖的版本进行了统一的管理维护。

7.1.2.4 属性配置

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

1). 自定义属性

<properties><lombok.version>1.18.24</lombok.version>
</properties>

2). 引用属性

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

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

<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> 是统一管理依赖版本，不会直接依赖，还需要在子工程中引入所需依赖(无需指定版本)

7.2 聚合

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

此时，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的聚合就可以轻松实现项目的一键构建（清理、编译、测试、打包、安装等）。

7.2.1 介绍

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

7.2.2 实现

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

<!--聚合其他模块-->
<modules><module>../tlias-pojo</module><module>../tlias-utils</module><module>../tlias-web-management</module>
</modules>

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

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

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

7.3 继承与聚合对比

作用
- 聚合用于快速构建项目
- 继承用于简化依赖配置、统一管理依赖
相同点：
- 聚合与继承的pom.xml文件打包方式均为pom，通常将两种关系制作到同一个pom文件中
- 聚合与继承均属于设计型模块，并无实际的模块内容
不同点：
- 聚合是在聚合工程中配置关系，聚合可以感知到参与聚合的模块有哪些
- 继承是在子模块中配置关系，父模块无法感知哪些子模块继承了自己

8. 私服

前面我们在讲解多模块开发的时候，我们讲到我们所拆分的模块是可以在同一个公司各个项目组之间进行资源共享的。这个模块的资源共享，就需要通过我们接下来所讲解的 Maven 的私服来实现。

8.1 场景

在介绍什么是私服之前，我们先来分析一下同一个公司，两个项目组之间如何基于私服进行资源的共享。

假设现在有两个团队，A 和 B。 A 开发了一个模块 tlias-utils，模块开发完毕之后，将模块打成jar包，并安装到了A的本地仓库。

那此时，该公司的B团队开发项目时，要想使用 tlias-utils 中提供的工具类，该怎么办呢？对于maven项目来说，是不是在pom.xml文件中引入 tlias-utils的坐标就可以了呢？

大家可以思考一下，当B团队在maven项目的pom.xml配置文件中引入了依赖的坐标之后，maven是如何查找这个依赖的？查找顺序为：

1). 本地仓库：本地仓库中是没有这个依赖jar包的。

2). 远程中央仓库：由于该模块时自己公司开发的，远程仓库中也没有这个依赖。

因为目前tlias-utils这个依赖，还在A的本地仓库中的。 B电脑上的maven项目，是不可能找得到A电脑上maven本地仓库的jar包的。那此时，大家可能会有一个想法：因为A和B都会连接中央仓库，我们可以将A本地仓库的jar包，直接上传到中央仓库，然后B从中央仓库中下载tlias-utils这个依赖。

这个想法很美好，但是现实很残酷。这个方案是行不通的，因为中央仓库全球只有一个，不是什么人都可以往中央仓库中来上传jar包的，我们是没有权限操作的。

那此时，maven的私服就出场了，私服其实就是架设在公司局域网内部的一台服务器，就是一种特殊的远程仓库。

有了私服之后，各个团队就可以直接来连接私服了。 A 连接上私服之后，他就可以把jar包直接上传到私服当中。我公司自己内部搭建的服务器，我是不是有权限操作呀，把jar包上传到私服之后，我让 B 团队的所有开发人员也连接同一台私服。连接上这一台私服之后，他就会根据坐标的信息，直接从私服当中将对应的jar包下载到自己的本地仓库，这样就可以使用到依赖当中所提供的一些工具类了。这样我们就可以通过私服来完成资源的共享。

而如果我们在项目中需要使用其他第三方提供的依赖，如果本地仓库没有，也会自动连接私服下载，如果私服没有，私服此时会自动连接中央仓库，去中央仓库中下载依赖，然后将下载的依赖存储在私服仓库及本地仓库中。

8.2 介绍

私服：是一种特殊的远程仓库，它是架设在局域网内的仓库服务，用来代理位于外部的中央仓库，用于解决团队内部的资源共享与资源同步问题。
依赖查找顺序：
- 本地仓库
- 私服仓库
- 中央仓库
注意事项：私服在企业项目开发中，一个项目/公司，只需要一台即可（无需我们自己搭建，会使用即可）。

8.3 资源上传与下载

8.3.1 步骤分析

资源上传与下载，我们需要做三步配置，执行一条指令。

第一步配置：在maven的配置文件中配置访问私服的用户名、密码。

第二步配置：在maven的配置文件中配置连接私服的地址(url地址)。

第三步配置：在项目的pom.xml文件中配置上传资源的位置(url地址)。

配置好了上述三步之后，要上传资源到私服仓库，就执行执行maven生命周期：deploy。

私服仓库说明：

RELEASE：存储自己开发的RELEASE发布版本的资源。

SNAPSHOT：存储自己开发的SNAPSHOT发布版本的资源。

Central：存储的是从中央仓库下载下来的依赖。

项目版本说明：

RELEASE(发布版本)：功能趋于稳定、当前更新停止，可以用于发行的版本，存储在私服中的RELEASE仓库中。

SNAPSHOT(快照版本)：功能不稳定、尚处于开发中的版本，即快照版本，存储在私服的SNAPSHOT仓库中。

8.3.2 具体操作

为了模拟企业开发，这里我准备好了一台服务器（192.168.150.101），私服已经搭建好了，我们可以访问私服测试

私服准备好了之后，我们要做如下几步配置：

1.设置私服的访问用户名/密码（在自己maven安装目录下的conf/settings.xml中的servers中配置）

<server><id>maven-releases</id><username>admin</username><password>admin</password>
</server><server><id>maven-snapshots</id><username>admin</username><password>admin</password>
</server>

2.设置私服依赖下载的仓库组地址（在自己maven安装目录下的conf/settings.xml中的mirrors、profiles中配置）

<mirror><id>maven-public</id><mirrorOf>*</mirrorOf><url>http://192.168.150.101:8081/repository/maven-public/</url>
</mirror>

<profile><id>allow-snapshots</id><activation><activeByDefault>true</activeByDefault></activation><repositories><repository><id>maven-public</id><url>http://192.168.150.101:8081/repository/maven-public/</url><releases><enabled>true</enabled></releases><snapshots><enabled>true</enabled></snapshots></repository></repositories>
</profile>

3.IDEA的maven工程的pom文件中配置上传（发布）地址(直接在tlias-parent中配置发布地址)

<distributionManagement><!-- release版本的发布地址 --><repository><id>maven-releases</id><url>http://192.168.150.101:8081/repository/maven-releases/</url></repository><!-- snapshot版本的发布地址 --><snapshotRepository><id>maven-snapshots</id><url>http://192.168.150.101:8081/repository/maven-snapshots/</url></snapshotRepository>
</distributionManagement>

配置完成之后，我们就可以在tlias-parent中执行deploy生命周期，将项目发布到私服仓库中。