Maven 是一款构建和管理 Java 项目的工具 。
Maven 高级内容包括 :
分模块设计与开发
继承与聚合
私服
1. 分模块设计与开发
1.1 介绍
所谓分模块设计，顾名思义指的就是我们在设计一个 Java 项目的时候，将一个 Java 项目拆分成多
个模块进行开发。
1). 未分模块设计的问题(也就是单体结构)
如果项目不分模块，也就意味着所有的业务代码是不是都写在这一个 Java 项目当中。随着这个项目
的业务扩张，项目当中的业务功能可能会越来越多。
假如我们开发的是一个大型的电商项目，里面可能就包括了商品模块的功能、搜索模块的功能、购物车
模块、订单模块、用户中心等等。这些所有的业务代码我们都在一个 Java 项目当中编写。
此时大家可以试想一下，假如我们开发的是一个大型的电商网站，这个项目组至少几十号甚至几百号开
发人员，这些开发人员全部操作这一个 Java 项目。此时大家就会发现我们项目管理和维护起来将会
非常的困难。而且大家再来看，假如在我们的项目当中，我们自己定义了一些通用的工具类以及通用的
组件，而公司还有其他的项目组，其他项目组也想使用我们所封装的这些组件和工具类，其实是非常不
方便的。因为 Java 项目当中包含了当前项目的所有业务代码，所以就造成了这里面所封装的一些组
件会难以复用。
总结起来，主要两点问题：不方便项目的维护和管理、项目中的通用组件难以复用。
2). 分模块设计
分模块设计我们在进行项目设计阶段，就可以将一个大的项目拆分成若干个模块，每一个模块都是独立
的
分模块设计就是将项目按照功能 / 结构拆分成若干个子模块，方便项目的管理维护、拓展，也方便模块
键的相互调用、资源共享。
2. 继承与聚合
在案例项目分模块开发之后啊，我们会看到 tlias-pojo 、 tlias-utils 、 tlias-web-management
中都引入了一个依赖 lombok 的依赖。我们在三个模块中分别配置了一次。
如果是做一个大型的项目，这三个模块当中重复的依赖可能会很多很多。如果每一个 Maven 模块里
面，我们都来单独的配置一次，功能虽然能实现，但是配置是比较 繁琐 的。
而接下来我们要讲解的 Maven 的继承用来解决这问题的。
2.1 继承
我们可以再创建一个父工程 tlias-parent ，然后让上述的三个模块 tlias-pojo 、 tlias
utils 、 tlias-web-management 都来继承这个父工程 。 然后再将各个模块中都共有的依赖，都
提取到父工程 tlias-parent 中进行配置，只要子工程继承了父工程，依赖它也会继承下来，这样就
无需在各个子工程中进行配置了
概念：继承描述的是两个工程间的关系，与 java 中的继承相似，子工程可以继承父工程中的配置
信息，常见于依赖关系的继承。
作用：简化依赖配置、统一管理依赖
实现
这是我们在这里先介绍一下什么是继承以及继承的作用，以及在 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 ，就可以了。 具
体结构如下：
2.1.1.2 实现
1). 创建 maven 模块 tlias-parent ，该工程为父工程，设置打包方式 pom( 默认 jar) 。
父工程 tlias-parent 的 pom.xml 文件配置如下：
Maven 打包方式：
jar ：普通模块打包， springboot 项目基本都是 jar 包（内嵌 tomcat 运行）
war ：普通 web 程序打包，需要部署在外部的 tomcat 服务器中运行
pom ：父工程或聚合工程，该模块不写代码，仅进行依赖管理
2). 在子工程的 pom.xml 文件中，配置继承关系。
这里是以 tlias-utils 为例，指定了其父工程。其他的模块，都是相同的配置方式。
注意：
在子工程中，配置了继承关系之后，坐标中的groupId是可以省略的，因为会自动继承父工
程的 。
relativePath指定父工程的pom文件的相对位置（如果不指定，将从本地仓库/远程仓库查
找该工程）。
../ 代表的上一级目录
3). 在父工程中配置各个工程共有的依赖（子工程会自动继承父工程的依赖）。
此时，我们已经将各个子工程中共有的依赖（ lombok ），都定义在了父工程中，子工程中的这一项依
赖，就可以直接删除了。删除之后，我们会看到父工程中配置的依赖 lombok ，子工程直接继承下来 了。
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 这个版本。
那假如说，我们项目要升级，要使用到 jwt 最新版本 0.9.2 中的一个新功能，那此时需要将依赖的版
本升级到 0.9.2 ，那此时该怎么做呢 ？ 第一步：去找当前项目中所有的模块的 pom.xml 配置文件，看哪些模块用到了 jwt 的依赖。
第二步：找到这个依赖之后，将其版本 version ，更换为 0.9.2 。
问题：如果项目拆分的模块比较多，每一次更换版本，我们都得找到这个项目中的每一个模块，一个一
个的更改。 很容易就会出现，遗漏掉一个模块，忘记更换版本的情况。
那我们又该如何来解决这个问题，如何来统一管理各个依赖的版本呢？
答案： Maven 的版本锁定功能。
2.1.2.2 介绍
在 maven 中，可以在父工程的 pom 文件中通过 <dependencyManagement> 来统一管理依赖版本。
父工程：
子工程：
注意：
在父工程中所配置的 <dependencyManagement> 只能统一管理依赖版本，并不会将这个
依赖直接引入进来。 这点和 <dependencies> 是不同的。
子工程要使用这个依赖，还是需要引入的，只是此时就无需指定 <version> 版本号了，
父工程统一管理。变更依赖版本，只需在父工程中统一变更。
2.1.2.3 属性配置
我们也可以通过自定义属性及属性引用的形式，在父工程中将依赖的版本号进行集中管理维护。 具体
语法为：
1). 自定义属性
2). 引用属性
版本集中管理之后，我们要想修改依赖的版本，就只需要在父工程中自定义属性的位置，修改对应的属
性值即可
面试题： <dependencyManagement> 与 <dependencies> 的区别是什么 ?
<dependencies> 是直接依赖，在父工程配置了依赖，子工程会直接继承下来。
<dependencyManagement> 是统一管理依赖版本，不会直接依赖，还需要在子工程中引入
所需依赖 ( 无需指定版本 )
2.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 的聚合就可以轻松实现项目的一键构建（清理、编译、测试、打包、安装
等）
2.2.1 介绍
聚合： 将多个模块组织成一个整体，同时进行项目的构建。
聚合工程： 一个不具有业务功能的 “ 空 ” 工程（有且仅有一个 pom 文件） 【 PS ：一般来说，继承关
系中的父工程与聚合关系中的聚合工程是同一个】
作用： 快速构建项目（无需根据依赖关系手动构建，直接在聚合工程上构建即可）
2.2.2 实现
在 maven 中，我们可以在聚合工程中通过 <moudules> 设置当前聚合工程所包含的子模块的名称。我
们可以在 tlias-parent 中，添加如下配置，来指定当前聚合工程，需要聚合的模块：
2.3 继承与聚合对比
作用
聚合用于快速构建项目
继承用于简化依赖配置、统一管理依赖
相同点：
聚合与继承的 pom.xml 文件打包方式均为 pom ，通常将两种关系制作到同一个 pom 文件中
聚合与继承均属于设计型模块，并无实际的模块内容
不同点：
聚合是在聚合工程中配置关系，聚合可以感知到参与聚合的模块有哪些
继承是在子模块中配置关系，父模块无法感知哪些子模块继承了自己
3. 私服
前面我们在讲解多模块开发的时候，我们讲到我们所拆分的模块是可以在同一个公司各个项目组之间进
行资源共享的。这个模块的资源共享，就需要通过我们接下来所讲解的 Maven 的私服来实现。
首先我们先介绍一下什么是私服，以及它的作用是什么。再来介绍一下我们如何将每位模块打包上传到
私服，以及从私服当中来下载。
3.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 包下载到自己的本地仓库，这样就可以使用到依赖当中所提供的一些工具类了。这
样我们就可以通过私服来完成资源的共享
而如果我们在项目中需要使用其他第三方提供的依赖，如果本地仓库没有，也会自动连接私服下载，如
果私服没有，私服此时会自动连接中央仓库，去中央仓库中下载依赖，然后将下载的依赖存储在私服仓
库及本地仓库中。
3.2 介绍
私服： 是一种特殊的远程仓库，它是架设在局域网内的仓库服务，用来代理位于外部的中央仓库，
用于解决团队内部的资源共享与资源同步问题。
依赖查找顺序：
本地仓库
私服仓库
中央仓库
注意事项： 私服在企业项目开发中，一个项目 / 公司，只需要一台即可（无需我们自己搭建，会使
用即可）
3.3 资源上传与下载
3.3.1 步骤分析
资源上传与下载，我们需要做三步配置，执行一条指令。
第一步配置：在 maven 的配置文件中配置访问私服的用户名、密码。
第二步配置：在 maven 的配置文件中配置连接私服的地址 (url 地址 ) 。
第三步配置：在项目的 pom.xml 文件中配置上传资源的位置 (url 地址 ) 。
配置好了上述三步之后，要上传资源到私服仓库，就执行执行 maven 生命周期： deploy 。
私服仓库说明：
RELEASE ：存储自己开发的 RELEASE 发布版本的资源。
SNAPSHOT ：存储自己开发的 SNAPSHOT 发布版本的资源。
Central ：存储的是从中央仓库下载下来的依赖
项目版本说明：
RELEASE( 发布版本 ) ：功能趋于稳定、当前更新停止，可以用于发行的版本，存储在私服中
的 RELEASE 仓库中。
SNAPSHOT( 快照版本 ) ：功能不稳定、尚处于开发中的版本，即快照版本，存储在私服的
SNAPSHOT 仓库中。
3.3.2 具体操作
访问私服服务器
1. 设置私服的访问用户名 / 密码（在自己 maven 安装目录下的 conf/settings.xml 中的 servers 中配
置）
2. 设置私服依赖下载的仓库组地址（在自己 maven 安装目录下的 conf/settings.xml 中的
mirrors 、 profiles 中配置）
3.IDEA 的 maven 工程的 pom 文件中配置上传（发布）地址 ( 直接在 tlias-parent 中配置发布地址 )
