【SSM学习】04-Maven高级

SSM（B站黑马）学习笔记

01-1-Spring概述
01-2-Spring IOC
01-3-Spring AOP
01-4-Spring 事务
02-SpringMVC
03-SSM整合
04-Maven高级
05-SpringBoot
06-MyBatisPlus

---

---

前言

SSM（B站黑马）学习笔记 04-Maven高级

---

04-Maven高级

分模块开发与设计

分模块开发的意义

银行系统从建国以后就有，那银行系统长什么样，长什么样不重要，重要的是它经历过了很多的阶段。最早的银行系统是账本，到了上世纪80年代就出现了电子系统，就是黑屏式的DOS窗口操作的，输入1 2 3 4回车执行对应的指令。二十一世纪以后又出现了网上银行，随着在本世纪智能手机的问世我们又有了手机银行APP，甚至现在还有数字化货币，这整体放到一块视为一个系统。你会发现我们的系统已经不简简单单的是有一个模块构成的，因为最早在开发DOS窗口操作模块，网上银行，手机银行APP这些概念都没有提出，是根据科技的发展逐步出现了各种各样对应的功能，因此开发出来了对应的模块。

我们的程序按照功能其实是可以划分成若干个模块的，除了按功能划分以外我们还可以进一步划分，比如现在做一个电商系统避免不了的要用到订单模块和商品模块，这两个功能在企业中是一个人在做，甚至是两个团队在做。那这个时候就有一个问题，做订单模块一定要用到做商品模块这个团队所制作出来的东西。最基本的，做订单模块的时候要去使用商品模块里面的实体类pojo。那这个时候就提出了一个问题，我们做商品开发的这个团队有可能或者说是一定要将它所制作的domain（pojo）其他的团队使用。那这个时候我们就发现原来这块东西要进行模块间的共享，不光是自己用，别人也要用。整个团队开发的东西大家都要用。这个时候就有人提出，我们能不能把domain（pojo）的功能独立的抽取出来，让所有团队都能够使用就像jar包一样让所有的人通过一个坐标（依赖）就可以导到自己的功能中。这就是分模块开发。

• 将原始模块按照功能拆分成若干子模块，方便模块间的相互调用，接口共享
  • 按照这样的结构进行设计的话，每一层功能只要想进行复用就可以很方便的被别人使用到
  • 好处：对每个模块独立维护、别人想使用的时候也方便

入门案例

案例初始化（上一节SSM整合整块内容）

1.分离pojo模块

新建模块

将pojo移动到新模块（02模块就会报错）

2.将03模块pojo导入到02模块

导入成功后02模块就会出现03模块的依赖

导入成功后02模块就不报错了，我们把其中一部分功能抽出来了，做出独立的模块。然后在原始的使用方（02模块）引用，做到分模块。
注意：企业开发是各做各的，然后引用，不是做好了再拆，这里只是演示

3.编译

04Maven&MyBatis
maven要运行执行的是生命周期的操作，运行最基本要通过编译，运行编译(compile)以后发现报错error，意思是执行生命周期的时候出现了问题，不能够解析到我们的这个依赖，哪个依赖，在我的工程中引用东西了，02引用了03他不能够找到这个artifact。说的简单一点就是，现在02里边写了引用这个03结果找不到。

原因是我们其它的依赖都是从中央仓库下载到本地仓库，本地仓库能找到spring之类的坐标，而我们的con.gdit现在在本地并没有。

解决：将03项目打包放进本地仓库。使用maven生命周期的install命令

再次编译02模块 成功编译

相同方法分离dao层

同样的方法做出dao层的独立模块，对应要使用的Mybatis等相关依赖也要导入到独立模块

启动Tomcat运行ssm项目还是能够正常访问

依赖管理

依赖传递

依赖指当前项目运行所需的jar包，一个项目可以设置多个依赖。例如maven_02_ssm项目中使用的依赖（如图），有自己开发的也有第三方开发的，而有些依赖左边带有箭头有些没有，箭头代表当前使用的依赖又依赖了别的依赖。这时就可以分成两大类，一类是我们pom.xml中直接导入的依赖——直接依赖，另一类是我们使用的依赖又有别的依赖——间接依赖。

因为04模块中也依赖了03模块，我们在02模块把03模块的直接依赖去掉只留下04模块，会发现项目还是可以正常运行。

这种现象称为依赖的传递性——依赖传递。就是当前项目可使用间接依赖
直接依赖和间接依赖是一直存在的，比如下图第二层直接依赖第三层，间接依赖第四层。

依赖传递冲突问题
依赖冲突是普遍存在的，假如上面第4层用的Mybatis 3 下面第5层用Mybatis 2或下面第4层用Mybatis 2用谁的

三种优先方法不用纠结死记，简单粗暴的方法就是调到想要用的依赖就行，maven工具提供了依赖的拓展图，直接显示了依赖的关系和深度

可选依赖

假如现在开发了一套程序，里面依赖了一些东西，为了不让别人知道他用到了哪些依赖，想把一些使用的依赖隐藏起来。为什么有这样的想法？假如我当前项目里面用到了一个依赖版本是5.1，但是又担心回头这套东西别人用的时候出现冲突问题。于是就干脆不告诉你，隐藏对外的资源依赖关系（切断依赖传递），就没有冲突问题了。

例如隐藏04dao模块中的03pojo依赖
隐藏前 因为依赖传递性所以02模块还能使用pojo

使用标签隐藏后 切断了依赖传递，02模块无法引用03pojo模块
true隐藏 fasle不隐藏

排除依赖

有时使用第三方依赖我们是无法在其内部设置可选依赖，而我们又不需要第三方资源的一些依赖。例如第三方资源日志使用log4j我们要在当前项目中剔除掉。

排除前

排除后
注意：不用写版本号，因为直接排除这门技术

可选依赖和排除依赖的区别，可选依赖是不给别人用，排除依赖是不用别人的。效果虽然相似，但功能完全不一样

聚合与继承

聚合

为避免修改单一模块导致其它模块不能使用，例如修改pojo模块往里增/减一个字段，其它不能用了。如果其它模块能够同时构建，出问题就能发现。这时就需要聚合工程用来管理其它模块，一个模块更新四个模块同时构建。在聚合工程点compile四个以前compile，点install四个一起install

新建聚合工程

修改打包方式为pom

编译
编译后四个工程都参与构建了
它构建的顺序会根据相互的依赖关系自动分配顺序，如图其它三个都依赖pojo所以它最先构建

继承

各个工程存在重复配置依赖的问题

• 概念：继承描述的是两个工程间的关系，与Java中的继承相似，子工程可以继承父工程中的配置信息，常见于依赖关系的继承
• 作用：
  • 简化配置
  • 减少版本冲突 （统一依赖版本）

案例：
1.在子工程中描述继承关系

2.配置父工程依赖（配置大部分类都要用的） 删除部分子工程依赖
刷新maven后02继承了01的依赖

同样的方法让04也继承01

设置可选继承依赖 在标签内的依赖子工程可自行选择是否继承不强制继承。

子工程选择继承 直接写junit依赖不用写版本

属性

属性

场景：统一修改版本号时，依赖过多容易出现漏改的情况导致冲突

解决方法：使用类似于变量统一修改 （属性），下图String只是便于理解

定义属性
<properties>标签内定义 标签名即为属性名 使用${}引用

配置文件加载属性
拓展属性的使用范围（在jdbc.properties文件中也使用pom.xml定义的属性 个人觉得太麻烦了没必要）

案例
1.pom.xml定义属性并在jdbc.properties引用

2.扩大maven控制范围
中间两段作用是让其到指定目录里的文件可以解析${} 而且这组数据通过maven读取到
刷新后01工程就会出现引用resources文件，因为继承的关系子项目也会出现引用resources文件

3.查看是否引用成功
可以不用启动工程，把02工程打包成一个war包查看配置是否加载成功
对01聚合工程执行install命令，让四个工程一起安装到本地仓库
执行后会发现报错，原因是maven在进行打war包的时候，它认为war包必须要web.xml文件，所以会出错（奇怪，我的项目没有也不报错）

解决办法1，新建一个空的web.xml文件
web.xml空文件

解决办法2，使用插件

上述方法二选一构建成功后找到war包内的jdbc.properties文件
加载成功

存在的问题
如果要加载多个resources怎么办，这里只支持写一个

使用${project.basedir}属性，该属性表示当前项目所在目录，因为子项目继承了01，所以子项目里面也具有了这样的功能，相当于每个项目都写了<directory>${project.basedir}/src/main/resources</directory>

版本管理

多环境配置与应用

多环境开发

一个项目在开发环境中用的本机数据库，上线运行后在生产环境中的数据库肯定不是本机，给到测试也有专门的数据库。那这样要写三套配置，让程序多环境开发

• maven提供配置多种环境的设定，帮助开发者使用过程中快速切换环境
  
  

案例
先注释掉原先连接配置

配置多环境
可设置某个配置是否为默认启动环境

install后就会连接默认环境

切换环境
方法一
右边菜单栏Profiles内选择对应的id install后进行切换

方法二：使用maven命令
mvn install -P 指定名称

跳过测试

maven每次执行指令的时候，如果它需要进行测试这个测试过程是无法避免的

此过程能够保证程序打包的是正常的，但有些时候可能有特殊情况，希望它直接打包跳过测试。

通过测试案例
方法1：点击右边菜单栏处的蓝色闪电按钮
此方法有个弊端，就是一下全部跳过了，无法指定跳过

方法2：使用maven命令
mvn 指令 -D skipTests

方法3：指定跳过
测试是一个插件，只能在插件的基础上进行工作
1.找到测试插件的名称

2.配置插件
全跳过

整体不跳过，排除不参与测试的内容

私服

私服简介

替代中央服务器出现的新的服务器，它的作用范围是在开发团队中或者是一个公司内的

• 私服是一台独立的服务器，用于解决团队内部的资源共享与资源同步问题

搭建Maven私服的方式有很多，以下是其中一种使用量比较大的实现方式:

• Nexus
  • Sonatype公司的一款maven私服产品
  • 下载地址：https://help.sonatype.com/repomanager3/download

私服安装

打开网址，根据需要选择对应的版本下载（下载网址打不开，用资料里的吧）

将压缩包解压（两个文件）

启动私服

打开第一个文件的bin，使用cmd进入该目录 （注意，目录不能有中文）

输入指令：nexus.exe /run nexus

这是相当于Tomcat服务器，要在网页使用 localhost:8081 默认端口8081

点击登录

弹出向导 根据提示进行相关设置

私服仓库分类

私服资源操作流程分析

(1)在没有私服的情况下，我们自己创建的服务都是安装在Maven的本地仓库中

(2)私服中也有仓库，我们要把自己的资源上传到私服，最终也是放在私服的仓库中

(3)其他人要想使用你所上传的资源，就需要从私服的仓库中获取

(4)当我们要使用的资源不是自己写的，是远程中央仓库有的第三方jar包，这个时候就需要从远程中央仓库下载，每个开发者都去远程中央仓库下速度比较慢(中央仓库服务器在国外)，私服就再准备一个仓库，用来专门存储从远程中央仓库下载的第三方jar包，第一次访问没有就会去远程中央仓库下载，下次再访问就直接走私服下载

(5)前面在介绍版本管理的时候提到过有SNAPSHOT（临时版）和RELEASE（正式版），如果把这两类的都放到同一个仓库，比较混乱，所以私服就把这两个种jar包放入不同的仓库

(6)上面我们已经介绍了有三种仓库，一种是存放SNAPSHOT的，一种是存放RELEASE还有一种是存放从远程仓库下载的第三方jar包，那么我们在获取资源的时候要从哪个仓库种获取呢?

(7)上传可以上传到指定仓库，但下载又指定仓库就很麻烦。为了方便获取，我们将所有的仓库编成一个组，我们只需要访问仓库组去获取资源。

所有私服仓库总共分为三大类:

宿主仓库hosted

• 保存无法从中央仓库获取的资源
  • 自主研发（各项目组都有一个仓库）
  • 第三方非开源项目,比如Oracle,因为是付费产品，所以中央仓库没有

代理仓库proxy

• 代理远程仓库，通过nexus访问其他公共仓库，例如中央仓库

仓库组group

• 将若干个仓库组成一个群组，简化配置
• 仓库组不能保存资源，属于设计型仓库

资源上传与下载

暂时跳过

---

注：

该内容是根据B站黑马程序员学习时所记，相关资料可在B站查询：黑马程序员2022最新SSM框架教程_Spring+SpringMVC+Maven高级+SpringBoot+MyBatisPlus企业实用开发技术