(七)、生命周期与插件
1.生命周期
Maven 构建生命周期描述的是一次构建过程中经历了多少个事件:
(1).Maven生命周期三阶段
- clean: 清理工作
- default: 核心工作，例如编译、测试、打包、部署等
- site: 产生报告，发布站点等
(2).Clean 生命周期
pre-clean执行一些需要在clean之前完成的工作clean移除所有上一次构建生成的文件post-clean执行一些需要在clean之后立刻完成的工作
(3).Default 生命周期
- validate（校验） 校验项目是否正确并且所有必要的信息可以完成项目的构建过程。
initialize（初始化） 初始化构建状态，比如设置属性值。generate-sources（生成源代码） 生成包含在编译阶段中的任何源代码。process-sources（处理源代码） 处理源代码，比如说，过滤任意值。generate-resources（生成资源文件） 生成将会包含在项目包中的资源文件。process-resources（处理资源文件） 复制和处理资源到目标目录，为打包阶段最好准备。- compile（编译） 编译项目的源代码。
process-classes（处理类文件） 处理编译生成的文件，比如说对Java class文件做字节码改善优化。generate-test-sources（生成测试源代码） 生成包含在编译阶段中的任何测试源代码。process-test-sources（处理测试源代码） 处理测试源代码，比如说，过滤任意值。generate-test-resources（生成测试资源文件） 为测试创建资源文件。process-test-resources（处理测试资源文件） 复制和处理测试资源到目标目录。test-compile（编译测试源码） 编译测试源代码到测试目标目录.process-test-classes（处理测试类文件） 处理测试源码编译生成的文件。- test（测试） 使用合适的单元测试框架运行测试（Juint是其中之一）。
prepare-package（准备打包） 在实际打包之前，执行任何的必要的操作为打包做准备。- package（打包） 将编译后的代码打包成可分发格式的文件，比如JAR、 WAR或者EAR文件。
pre-integration-test（集成测试前） 在执行集成测试前进行必要的动作。比如说，搭建需要的环境。integration-test（集成测试） 处理和部署项目到可以运行集成测试环境中。post-integration-test（集成测试后） 在执行集成测试完成后进行必要的动作。比如说，清理集成测试环境。- verify （验证） 运行任意的检查来验证项目包有效且达到质量标准。
- install（安装） 安装项目包到本地仓库，这样项目包可以用作其他本地项目的依赖。
- deploy（部署） 将最终的项目包复制到远程仓库中与其他开发者和项目共享。
(4).Site生命周期
- pre-site 执行一些需要在生成站点文档之前完成的工作
- site 生成项目的站点文档
- post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备
- site-deploy 将生成的站点文档部署到特定的服务器上
2.插件
(1).插件的定义
- 插件与生命周期内的阶段绑定，在执行到对应生命周期时执行对应的插件功能
默认 maven 在各个生命周期上绑定有预设的功能- 通过插件可以自定义其他功能
(2).插件的用列
eg: 我们自定义在test测试的时候，进行打包的操作。
<build> <!--设置插件--> <plugins> <!-- 打包插件 --> <plugin> <!-- 三件套 --> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-source-plugin</artifactId> <version>2.2.1</version> <!-- 执行集合 --> <executions> <!-- 具体执行 --> <execution> <!-- 执行目标 --> <goals> <!-- 具体执行目标 --> <goal>jar</goal> </goals> <phase>generate-test-resources</phase> </execution> </executions> </plugin> </plugins> </build>
当我们点击生命周期的test的时候，我们发现帮助我们打成了一个jar包
(八)、分模块开发与设计
在实际开发中，dao、service、controller是不可能全部同时有一个人做的，也就是说我们的dao、service、contollrt是需要进行分包的操作的。
1.拆分springMvc_ssm项目
(1).ssm_pojo 拆分
- 新建模块
- 拷贝原始项目中对应的相关内容到 ssm_pojo 中
实体类 User- 配置文件无
(2).ssm_dao 拆分
- 新建模块
- 拷贝原始项目中对应的相关内容到 ssm_dao 中
数据层接口UserDao配置文件: 保留与数据层相关配置文件（3 个）
- 注意：分页插件在配置中与 SqlSessionFactoryBean 绑定，需要保留
pom.xml: 引入数据层相关坐标即可，删除 springmvc 相关坐标
- spring
- mybatis
- spring 整合 mybatis
- mysql
- druid
- pagehelper
- 直接依赖 ssm_pojo (对 ssm_pojo 模块执行 install 指令，将其安装到本地仓库）
ssm_service 拆分
注意: 我们发现问题,我们发现我们的dao层项目中需要使用到实体类，但是我们的dao项目中没有放实体的项目，所以我们需要对原先的 ssm_pojo进行安装到本地的仓库，然后我们在ssm_dao层使用三件套引用即可。
(3).ssm_service 拆分
- 新建模块
- 拷贝原始项目中对应的相关内容到 ssm_service 模块中
业务层接口与实现类(UserService、UserServiceImpl)配置文件：保留与数据层相关配置文件（1个）pom.xml: 引入数据库相关坐标即可，删除 springmvc 相关坐标
- spring
- junit
- spring 整合 junit
- 直接依赖 ssm_dao （对 ssm_dao 模块执行 install 指令， 将其安装到本地仓库）
- 间接依赖 ssm_pojo（由 ssm_dao 模块负责依赖关系的建立）
- 修改 service 模块 spring 核心配置文件名，添加模块名称, 格式：applicationContext-service.xml
- 修改 dao 模块 spring 核心配置文件名，添加模块名称，格式：applicationContext-dao.xml
- 修改单元测试引入的配置文件名称，由单个文件修改为多个文件
注意: 因为我们的service层是需要我们的ssm_dao层的接口和实现类的，所以我们需要在ssm_dao 进行 install的操作，又因为我们ssm_dao install ssm_pojo， 所以直接依赖ssm_dao,间接依赖ssm_pojo。
(4).ssm_controller 拆分
- 新建模板（使用 webapp 模板)
- 拷贝原始项目中对应的相关内容到 ssm_controller 模块中
表现层控制器类与相关设置类（UserController，异常相关)配置文件：保留与表现层相关配置文件（1个）、服务器相关配置文件（1个）pom.xml：引入数据层相关坐标即可，删除 springmvc 相关坐标
- spring
- springmvc
- jackson
- servlet
- tomcat 服务器插件
- 直接依赖 ssm_service（对 ssm_service 模块执行 install 指令，将其安装到本地仓库）
- 间接依赖 ssm_dao、ssm_pojo
- 修改 web.xml 配置文件中加载 spring 环境的配置文件名称，使用 * 通配，加载所有 applicationContext- 开始的配置文件
运行的话，我们只需要运行Controller即可。因为我们其他的资源都放在本地仓库了，所以不需要进行启动其他的业务即可。
(5).分模块开发小结
- 模块仅包含当前模块对应的功能类与配置文件
- spring 核心配置根据模块功能不同进行独立制作
- 当前模块所依赖的模块通过导入坐标的形式加入当前模块后才可以使用
- web.xml 需要加载所有的 spring 核心配置文件
2.模块聚合
(1).多模块构建维护
在实际开发的过程中，我们会有很多模块，但是假如我们对一个模块进行更新后，其他模块不知到它更新。那么这个服务就会启动不起来。所以我们现在迫切需要一个统一的管理模块，负责管理我们的4个模块，当这个统一的模块更新的时候，这管理的所有模块都将一起进行更新，谁都不会落下。
(2).聚合
- 作用：聚合用于快速构建 maven 工程，一次性构建多个项目/模块。
- 制作方式：
- 创建一个空模块，打包类型定义为 pom
<!--定义该工程用于进行构建管理 --> <packaging>pom</packaging>
- 定义当前模块进行构建操作时关联的其他模块名称
<!-- 管理的工程列表 --> <modules> <!-- 具体的工程 --> <module>../ssm_controller</module> <module>../ssm_service</module> <module>../ssm_dao</module> <module>../ssm_pojo</module> </modules>
注意事项：参与聚合操作的模块最终执行顺序与模块间的依赖关系有关，与配置顺序无关;
3.模块继承
(1).多模块继承
比如说: 在我们日常开发中，我们使用多模块开发的时候，会遇到如下的问题:“我们在开发一个SpringBoot项目会出现版本依赖的版本号不一致的问题，所以我们需要对我们所有使用的公共版本号进行统一管理，避免出现不兼容的问题”。
作用：通过继承可以实现在子工程中沿用父工程中的 配置
- maven 中的继承与 java 中的继承相似，在子工程中配置继承关系
(2).继承
我们不仅可以对版本依赖的版本号可以进行统一的管理，而且我们也可以使用 插件管理器 对其进行版本控制。
- 父工程进行声明的操作
<!-- 声明此处进行依赖管理--> <dependencyManagement> <!-- 具体的依赖集合 --> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.13.2</version> <scope>test</scope> </dependency> </dependencies> </dependencyManagement>
- 子工程和父工程进行联系
<!-- 给这个子工程进行指定其父工程的位置是哪个--> <parent> <!-- 这里设置三件套 --> <artifactId>Maven_Idea</artifactId> <groupId>com.jsxs</groupId> <version>1.0-SNAPSHOT</version> <!-- 这里我们需要指定父工程的pom.xml文件--> <relativePath>pom.xml</relativePath> </parent>
- 在子工程中定义依赖关系，无需声明依赖版本，版本参照父工程中依赖的版本
<dependencies> <!-- spring 环境 --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> </dependency> </dependencies>
(3).继承的资源
(4).继承与聚合
- 作用
- 聚合用于
快速构建项目 - 继承用于
快速配置
- 相同点
- 聚合与继承 的 pom.xml
文件打包方式均为 pom，可以将两种关系制作到同一个 pom 文件中 - 聚合与继承 均属于 设计型模块，并无实际模块内容
- 不同点
- 聚合是在当前模块中配置关系，
聚合可以感知到参与聚合的模块有哪些 - 继承是在子模块中配置关系，
父模块无法感知哪些子模块继承了自己
4.属性
我们现在已经成功的解决了 父模块 与 子模块 之间的版本信息冲突的操作， 现在还存在着一种就是 父模块内部之间的版本依赖问题，比如说:“我们父工程内部使用mybatis与spring的时候要使用统一的版本号管理操作”
(1).自定义属性
- 作用：等同于定义变量，方便统一维护
- 定义格式：
<properties> <!-- 基本格式为: 技术名称.version--> <maven.compiler.source>8</maven.compiler.source> <maven.compiler.target>8</maven.compiler.target> <spring.version>5.1.9</spring.version> </properties>
使用格式
<version>${spring.version}</version>
(2).内置属性
- 作用：使用 maven 内置属性，快速配置
- 调用格式:
${basedir} ${version}
(3).Setting 属性
- 作用：使用 maven 配置文件 settings.xml 中的标签属性，用于动态配置
- 调用格式
${settings.localRepository}
(4).Java 系统属性
- 作用: 读取 Java 系统属性
- 调用格式
${user.home}
- 系统属性查询方式
mvn help:system
(5).环境变量属性
- 调用格式
${env.JAVA_HOME} • 1
- 环境变量属性查询方式
mvn help:system • 1
5.版本管理
(1).工程版本
- SNAPSHOT (快照版本）
项目开发过程中，为方便团队成员合作，解决模块间相互依赖和不时更新的问题，开发者对每个模块进行构建的时候，输出的临时性版本叫快照版本（测试阶段版本）
快照版本会随着开发的进展不断更新。 - RELEASE (发布版本）
项目开发进入阶段里程碑后，向团队外部发布较为稳定的版本，这种版本所对应的构件文件是稳定的，即便进行功能的后续开发，也不会改变当前发布版本内容，这种版本称为发布版本。
(2).工程版本号约定
- 约定规范
- <主版本>.<次版本>.<增量版本>.<里程碑版本>
- 主版本：表示项目重大架构的变更，如: spring 5 相较于 spring 4 的迭代
- 次版本：表示有较大的功能增加和变化，或者全面系统地修复漏洞
- 增量版本：表示有重大漏洞的修复
- 里程碑版本：表明一个版本的里程碑（版本内部）。这样的版本
- 范例
5.1.9.RELEASE
