Maven高级
1，分模块开发
1.1 分模块开发设计
(1)按照功能拆分：将原始模块按照功能拆分成若干个子模块，方便模块间的相互调用，接口共享。避免单模块代码的异常导致整个项目无法正常运行
我们现在的项目都是在一个模块中，比如前面的SSM整合开发。虽然这样做功能也都实现了，但是也存在了一些问题，我们拿银行的项目为例：银行柜台或者取款机进行业务操作、在网页上登录银行网站使用U盾进行业务操作、用手机登录APP就可以进行业务操作，如果非要把三个场景的模块代码放入到一个项目，那么当其中某一个模块代码出现问题，就会导致整个项目无法正常启动，从而导致银行的多个业务都无法正常班理。所以我们会按照功能将项目进行拆分。
(2)按照模块拆分：多模块中具有重复的模型类，提取公共部分为单独模块，其他模块通过导入的方式使用，避免代码重复
比如电商的项目中，有订单和商品两个模块，订单中需要包含商品的详细信息，所以需要商品的模型类，商品模块也会用到商品的模型类，这个时候如果两个模块中都写模型类，就会出现重复代码，后期的维护成本就比较高。我们就想能不能将它们公共的部分抽取成一个独立的模块，其他模块要想使用可以像添加第三方jar包依赖一样来使用我们自己抽取的模块，这样就解决了代码重复的问题,这种拆分方式就说我们所说的按照模块拆分。
刚刚我们说了可以将domain层进行拆分，除了domain层，我们也可以将其他的层也拆成一个个对立的模块，项目中的每一层都可以单独维护，也可以很方便的被别人使用。如:
1.2 分模块开发实现
前面我们已经完成了SSM整合，接下来，咱们就基于SSM整合的项目来实现对项目的拆分。
1.2.1 环境准备
将资料\maven_02_ssm部署到IDEA中，将环境快速准备好，部署成功后，项目的格式如下:
1.2.2 抽取domain层
步骤1:创建新Maven模块
创建一个名称为maven_03_pojo的jar项目,为什么项目名是从02到03这样创建，原因后面我们会提到，这块的名称可以任意。
步骤2:项目中创建domain包
在maven_03_pojo项目中创建com.itheima.domain包，并将maven_02_ssm中Book类拷贝到该包中
步骤3:删除原项目中的domain包
删除后，maven_02_ssm项目中用到Book的类中都会有红色提示，如下:
**说明:**出错的原因是maven_02_ssm中已经将Book类删除，所以该项目找不到Book类，所以报错
要想解决上述问题，我们需要在maven_02_ssm中添加maven_03_pojo的依赖。
步骤4:建立依赖关系
在maven_02_ssm项目的pom.xml添加maven_03_pojo的依赖
<dependency>
<groupId>com.itheimagroupId>
<artifactId>maven_03_pojoartifactId>
<version>1.0-SNAPSHOTversion>
dependency>
因为添加了依赖，所以在maven_02_ssm中就已经能找到Book类，所以刚才的报红提示就会消失。
步骤5:编译maven_02_ssm项目
编译maven_02_ssm你会在控制台看到如下错误
错误信息为：不能解决maven_02_ssm项目的依赖问题，找不到maven_03_pojo这个jar包。
为什么找不到呢?
原因是Maven会从本地仓库找对应的jar包，但是本地仓库又不存在该jar包所以会报错。
在IDEA中是有maven_03_pojo这个项目，所以我们只需要将maven_03_pojo项目安装到本地仓库即可。
步骤6:将项目安装本地仓库
将需要被依赖的项目maven_03_pojo，使用maven的install命令，把其安装到Maven的本地仓库中。
安装成功后，在对应的路径下就看到安装好的jar包
**说明:**具体安装在哪里，和你们自己电脑上Maven的本地仓库配置的位置有关。
当再次执行maven_02_ssm的compile的命令后，就已经能够成功编译。
1.2.3 抽取Dao层
步骤1:创建新Maven模块
创建一个名称为maven_04_dao的jar项目
步骤2:项目中创建dao包
在maven_04_dao项目中创建com.itheima.dao包，并将maven_02_ssm中BookDao类拷贝到该包中
在maven_04_dao中会有如下几个问题需要解决下: 添加依赖
-
项目
maven_04_dao的BookDao接口中Book类找不到报错:-
解决方案在
maven_04_dao项目的pom.xml中添加maven_03_pojo项目<dependencies> <dependency> <groupId>com.itheimagroupId> <artifactId>maven_03_pojoartifactId> <version>1.0-SNAPSHOTversion> dependency> dependencies>
-
-
项目
maven_04_dao的BookDao接口中，Mybatis的增删改查注解报错-
解决方案在
maven_04_dao项目的pom.xml中添加mybatis的相关依赖<dependencies> <dependency> <groupId>org.mybatisgroupId> <artifactId>mybatisartifactId> <version>3.5.6version> dependency> <dependency> <groupId>mysqlgroupId> <artifactId>mysql-connector-javaartifactId> <version>5.1.47version> dependency> dependencies>
-
步骤3:删除原项目中的dao包
删除Dao包以后，因为maven_02_ssm中的BookServiceImpl类中有使用到Dao的内容，所以需要在maven_02_ssm的pom.xml添加maven_04_dao的依赖
<dependency>
<groupId>com.itheimagroupId>
<artifactId>maven_04_daoartifactId>
<version>1.0-SNAPSHOTversion>
dependency>
此时在maven_02_ssm项目中就已经添加了maven_03_pojo和maven_04_dao包
同样将maven_04_dao安装到Maven的本地仓库，再次对maven_02_ssm项目进行compile编译即可。
1.2.4 运行测试并总结
将抽取后的项目进行运行，测试之前的增删改查功能依然能够使用。
所以对于项目的拆分，大致会有如下几个步骤:
(1) 创建Maven模块
(2) 书写模块代码：先针对模块功能进行设计，再进行编码（不是先开发再拆分）
(3)通过maven指令安装模块到本地仓库(install 指令)
团队内部开发需要发布模块功能到团队内部可共享的仓库中(私服)，私服我们后面会讲解。
2，依赖管理
我们现在已经能把项目拆分成一个个独立的模块，当在其他项目中想要使用独立出来的这些模块，只需要在其pom.xml使用标签来进行jar包的引入即可。
其实就是依赖，关于依赖管理的内容，我们就一个个来学习下:
- 依赖传递
- 可选依赖
- 排除依赖
我们先来说说什么是依赖:
依赖指当前项目运行所需的jar，一个项目可以设置多个依赖。
格式为:
<dependencies>
<dependency>
<groupId>org.springframeworkgroupId>
<artifactId>spring-webmvcartifactId>
<version>5.2.10.RELEASEversion>
dependency>
dependencies>
2.1 依赖传递与冲突问题
回到我们刚才的项目案例中，打开Maven的面板，你会发现:
在项目所依赖的这些jar包中，有一个比较大的区别就是有的依赖前面有箭头>,有的依赖前面没有。
那么这个箭头所代表的含义是什么?
打开前面的箭头，你会发现这个jar包下面还包含有其他的jar包
依赖传递：依赖是具有传递性的
**说明:**A代表自己的项目；B,C,D,E,F,G代表的是项目所依赖的jar包；D1和D2 E1和E2代表是相同jar包的不同版本
(1) A依赖了B和C,B和C有分别依赖了其他jar包，所以在A项目中就可以使用上面所有jar包，这就是所说的依赖传递
(2) 依赖传递有直接依赖和间接依赖
- 相对于A来说，A直接依赖B和C,间接依赖了D1,E1,G，F,D2和E2
- 相对于B来说，B直接依赖了D1和E1,间接依赖了G
- 直接依赖和间接依赖是一个相对的概念
(3)因为有依赖传递的存在，就会导致jar包在依赖的过程中出现冲突问题，具体什么是冲突?Maven是如何解决冲突的?
依赖冲突是指项目依赖的某一个jar包，有多个不同的版本，因而造成类包版本冲突。（同级后者优先，不同级前者优先，同层级先配置的优先）
情况一: * 特殊优先：当同级配置了相同资源的不同版本，后配置的覆盖先配置的。
例如：在maven_02_ssm的pom.xml中添加两个不同版本的Junit依赖:
情况二: 路径优先：当依赖中出现相同的资源时，层级越深，优先级越低，层级越浅，优先级越高
- A通过B间接依赖到E1
- A通过C间接依赖到E2
- A就会间接依赖到E1和E2,Maven会按照层级来选择，E1是2度，E2是3度，所以最终会选择E1
情况三: 声明优先：当资源在相同层级被依赖时，配置顺序靠前的覆盖配置顺序靠后的
- A通过B间接依赖到D1
- A通过C间接依赖到D2
- D1和D2都是两度，这个时候就不能按照层级来选择，需要按照声明来，谁先声明用谁，也就是说B在C之前声明，这个时候使用的是D1，反之则为D2
注：对应上面这些结果，大家不需要刻意去记它。因为不管Maven怎么选，最终的结果都会在Maven的
Dependencies面板中展示出来，展示的是哪个版本，也就是说它选择的就是哪个版本
如果想更全面的查看Maven中各个坐标的依赖关系，可以点击Maven面板中的show Dependencies，展示出jar包之间的相互依赖关系。
2.2 可选依赖和排除依赖(某些依赖不传递)
依赖传递介绍完以后，我们来思考一个问题，
- maven_02_ssm 依赖了 maven_04_dao，maven_04_dao 依赖了 maven_03_pojo， 因为现在有依赖传递，所以maven_02_ssm能够使用到maven_03_pojo的内容
- 如果说现在不想让maven_02_ssm依赖到maven_03_pojo（实际是需要的），有哪些解决方案?
即： A依赖B,B依赖C,C通过依赖传递会被A使用到，现在要想办法让A不去依赖C- 可选依赖是在B上设置
A不知道有C的存在， - 排除依赖是在A上设置
A知道有C的存在，主动将其排除掉。
方案一:可选依赖：对外隐藏当前所依赖的资源—不透明、隐藏后对应资源将不具有依赖传递
在maven_04_dao的pom.xml,在引入maven_03_pojo的时候，添加optional
<dependency>
<groupId>com.itheimagroupId>
<artifactId>maven_03_pojoartifactId>
<version>1.0-SNAPSHOTversion>
<optional>trueoptional>
dependency>
可选依赖实现了阻断maven_03_pojo的依赖传递
方案二:排除依赖 ：主动断开依赖的资源，被排除的资源无需指定版本—不需要
排除依赖，则指的是已经有依赖的事实，也就是说maven_02_ssm项目中已经通过依赖传递用到了maven_03_pojo，此时我们需要做的是将其进行排除，所以接下来需要修改maven_02_ssm的pom.xml
<dependency>
<groupId>com.itheimagroupId>
<artifactId>maven_04_daoartifactId>
<version>1.0-SNAPSHOTversion>
<exclusions>
<exclusion>
<groupId>com.itheimagroupId>
<artifactId>maven_03_pojoartifactId>
exclusion>
exclusions>
dependency>
当然exclusions标签带s说明我们是可以依次排除多个依赖到的jar包
3，聚合和继承
项目一旦变成了多模块开发以后，就会引发一些问题，在这一节中我们主要会学习两个内容聚合和继承，用这两个知识来解决下分模块后的一些问题。
3.1 聚合:抽取一个项目，把所有的项目管理起来
存在的问题:
- 分模块开发后，需要将这四个项目都安装到本地仓库，目前我们只能通过项目Maven面板的
install来安装，并且需要安装四个，如果我们的项目足够多，那么一个个安装起来还是比较麻烦的 - 如果四个项目都已经安装成功，当ssm_pojo发生变化后，我们就得将ssm_pojo重新安装到maven仓库，但是为了确保我们对ssm_pojo的修改不会影响到其他项目模块，我们需要对所有的模块进行重新编译，那又需要将所有的模块再来一遍
- 如果项目多的话，一个个操作项目就容易出现漏掉或重复操作的问题，
解决思路：能不能抽取一个项目，把所有的项目管理起来，以后我们要想操作这些项目，只需要操作这一个项目，其他所有的项目都走一样的流程，这个不就很省事省力。即：聚合
- 聚合:将多个模块组织成一个整体，同时进行项目构建的过程称为聚合
- 聚合工程：通常是一个不具有业务功能的"空"工程（有且仅有一个pom文件）
- 作用：使用聚合工程可以将多个工程编组，通过对聚合工程进行构建，实现对所包含的模块进行同步构建
- 当工程中某个模块发生更新（变更）时，必须保障工程中与已更新模块关联的模块同步更新，此时可以使用聚合工程来解决批量模块同步构建的问题。
- 聚合工程主要是用来管理项目。
关于聚合具体的实现步骤为:
步骤1:创建一个空的maven项目
步骤2:将项目的打包方式改为pom
<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">
<modelVersion>4.0.0modelVersion>
<groupId>com.itheimagroupId>
<artifactId>maven_01_parentartifactId>
<version>1.0-RELEASEversion>
<packaging>pompackaging>
project>
**说明:**项目的打包方式，我们接触到的有三种，分别是
- jar:默认情况，说明该项目为java项目
- war:说明该项目为web项目
- pom:说明该项目为聚合或继承(后面会讲)项目
步骤3:pom.xml添加所要管理的项目
<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">
<modelVersion>4.0.0modelVersion>
<groupId>com.itheimagroupId>
<artifactId>maven_01_parentartifactId>
<version>1.0-RELEASEversion>
<packaging>pompackaging>
<modules>
<module>../maven_02_ssmmodule>
<module>../maven_03_pojomodule>
<module>../maven_04_daomodule>
modules>
project>
步骤4:使用聚合统一管理项目
测试发现，当maven_01_parent的compile被点击后，所有被其管理的项目都会被执行编译操作。这就是聚合工程的作用。
说明：聚合工程管理的项目在进行运行的时候，会按照项目与项目之间的依赖关系来自动决定执行的顺序和配置的顺序无关。
3.2 继承
父工程主要是用来快速配置依赖jar包和管理项目中所使用的资源。
存在的问题 ：多模块开发存在的另外一个问题，重复配置的问题，（依赖具有传递性，模块配置中的依赖重复）我们先来看张图:
spring-webmvc、spring-jdbc在三个项目模块中都有出现，这样就出现了重复的内容：继承父工程spring-test只在ssm_crm和ssm_goods中出现，而在ssm_order中没有，这里是部分重复的内容：父工程中配置可选依赖- 我们使用的spring版本目前是
5.2.10.RELEASE,假如后期要想升级spring版本，所有跟Spring相关jar包都得被修改，涉及到的项目越多，维护成本越高
解决思路：继承
- 继承:描述的是两个工程间的关系，与java中的继承相似，子工程可以继承父工程中的配置信息，常见于依赖关系的继承。
- 作用：
- 简化配置
- 将所有项目公共的jar包依赖提取到父工程的pom.xml中，子项目就可以不用重复编写，简化开发
- 减少版本冲突
- 将所有项目的jar包配置到父工程的dependencyManagement标签下，实现版本管理，方便维护
- dependencyManagement标签不真正引入jar包，只是管理jar包的版本，管理可选依赖
- 子项目在引入的时候，只需要指定groupId和artifactId，不需要加version
- 当dependencyManagement标签中jar包版本发生变化，所有子项目中有用到该jar包的地方对应的版本会自动随之更新
- 简化配置
接下来，我们到程序中去看看继承该如何实现?
步骤1:创建一个空的Maven项目并将其打包方式设置为pom
实际开发中，聚合和继承一般也都放在同一个项目中，但是这两个的功能是不一样的。
步骤2:在子项目中设置其父工程
分别在maven_02_ssm,maven_03_pojo,maven_04_dao的pom.xml中添加其父项目为maven_01_parent
<parent>
<groupId>com.itheimagroupId>
<artifactId>maven_01_parentartifactId>
<version>1.0-RELEASEversion>
<relativePath>../maven_01_parent/pom.xmlrelativePath>
parent>
步骤3:优化子项目共有依赖导入问题
将子项目共同使用的jar包都抽取出来，维护在父项目的pom.xml中，并删除子项目中已经被抽取到父项目的pom.xml中的jar包
<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">
<modelVersion>4.0.0modelVersion>
<groupId>com.itheimagroupId>
<artifactId>maven_01_parentartifactId>
<version>1.0-RELEASEversion>
<packaging>pompackaging>
<modules>
<module>../maven_02_ssmmodule>
<module>../maven_03_pojomodule>
<module>../maven_04_daomodule>
modules>
<dependencies>
<dependency>
<groupId>org.springframeworkgroupId>
<artifactId>spring-coreartifactId>
<version>5.2.10.RELEASEversion>
dependency>
<dependency>
<groupId>org.springframeworkgroupId>
<artifactId>spring-webmvcartifactId>
<version>5.2.10.RELEASEversion>
dependency>
<dependency>
<groupId>org.springframeworkgroupId>
<artifactId>spring-jdbcartifactId>
<version>5.2.10.RELEASEversion>
dependency>
<dependency>
<groupId>org.springframeworkgroupId>
<artifactId>spring-testartifactId>
<version>5.2.10.RELEASEversion>
dependency>
<dependency>
<groupId>org.mybatisgroupId>
<artifactId>mybatisartifactId>
<version>3.5.6version>
dependency>
<dependency>
<groupId>org.mybatisgroupId>
<artifactId>mybatis-springartifactId>
<version>1.3.0version>
dependency>
<dependency>
<groupId>mysqlgroupId>
<artifactId>mysql-connector-javaartifactId>
<version>5.1.47version>
dependency>
<dependency>
<groupId>com.alibabagroupId>
<artifactId>druidartifactId>
<version>1.1.16version>
dependency>
<dependency>
<groupId>javax.servletgroupId>
<artifactId>javax.servlet-apiartifactId>
<version>3.1.0version>
<scope>providedscope>
dependency>
<dependency>
<groupId>com.fasterxml.jackson.coregroupId>
<artifactId>jackson-databindartifactId>
<version>2.9.0version>
dependency>
dependencies>
project>
- 删除完后，你会发现父项目中有依赖对应的jar包，子项目虽然已经将重复的依赖删除掉了，但是刷新的时候，子项目中所需要的jar包依然存在。
- 将子项目中的公共jar包抽取到父工程中进行统一添加依赖，这样做的可以简化配置，并且当父工程中所依赖的jar包版本发生变化，所有子项目中对应的jar包版本也会跟着更新。
- 当项目的
步骤4:优化子项目依赖版本问题
如果把所有用到的jar包都管理在父项目的pom.xml，看上去更简单些，但是这样就会导致有很多项目引入了过多自己不需要的jar包。
如果把所有的依赖都放在了父工程中进行统一维护，就会导致ssm_order项目中多引入了spring-test的jar包，如果这样的jar包过多的话，对于ssm_order来说也是一种"负担"。
那针对于这种部分项目有的jar包，我们该如何管理优化呢?
- 在父工程mavne_01_parent的pom.xml来定义依赖管理
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junitgroupId>
<artifactId>junitartifactId>
<version>4.12version>
<scope>testscope>
dependency>
dependencies>
dependencyManagement>
- 将maven_02_ssm的pom.xml中的junit依赖删除掉，刷新Maven
刷新完会发现，在maven_02_ssm项目中的junit依赖并没有出现，所以我们得到一个结论:
- 在maven_02_ssm、maven_04_dao的pom.xml添加junit的依赖
<dependency>
<groupId>junitgroupId>
<artifactId>junitartifactId>
<scope>testscope>
dependency>
注意：这里就不需要添加版本了，这样做的好处就是当父工程dependencyManagement标签中的版本发生变化后，子项目中的依赖版本也会跟着发生变化 =》 减少版本冲突
这个时候，maven_02_ssm和maven_04_dao这两个项目中的junit版本就会跟随着父项目中的标签dependencyManagement中junit的版本发生变化而变化。不需要junit的项目就不需要添加对应的依赖即可。
继承的实现步骤:
-
创建Maven模块，设置打包类型为pom
<packaging>pompackaging> -
在父工程的pom文件中配置依赖关系(子工程将沿用父工程中的依赖关系),一般只抽取子项目中公有的jar包
<dependencies> <dependency> <groupId>org.springframeworkgroupId> <artifactId>spring-webmvcartifactId> <version>5.2.10.RELEASEversion> dependency> ... dependencies> -
在父工程中配置子工程中可选的依赖关系
<dependencyManagement> <dependencies> <dependency> <groupId>com.alibabagroupId> <artifactId>druidartifactId> <version>1.1.16version> dependency> dependencies> ... dependencyManagement> -
在子工程中配置当前工程所继承的父工程
<parent> <groupId>com.itheimagroupId> <artifactId>maven_01_parentartifactId> <version>1.0-RELEASEversion> <relativePath>../maven_01_parent/pom.xmlrelativePath> parent> -
在子工程中配置使用父工程中可选依赖的坐标
<dependencies> <dependency> <groupId>com.alibabagroupId> <artifactId>druidartifactId> dependency> dependencies>注意事项:
1.子工程中使用父工程中的可选依赖时，仅需要提供群组id和项目id，无需提供版本，版本由父工程统一提供，避免版本冲突
2.子工程中还可以定义父工程中没有定义的依赖关系,只不过不能被父工程进行版本统一管理。
3.3 聚合与继承的区别
3.3.1 聚合与继承的区别
两种之间的作用:
- 聚合用于快速构建项目，对项目进行管理
- 继承用于快速配置和管理子项目中所使用jar包的版本
聚合和继承的相同点:
- 聚合与继承的pom.xml文件打包方式均为pom，可以将两种关系制作到同一个pom文件中
- 聚合与继承均属于设计型模块，并无实际的模块内容
聚合和继承的不同点:
- 聚合是在当前模块中配置关系，聚合可以感知到参与聚合的模块有哪些
- 继承是在子模块中配置关系，父模块无法感知哪些子模块继承了自己
在聚合和继承的工程构建时，需要在聚合项目中手动添加modules标签，需要在所有的子项目中添加parent标签，手动添加标签容易出错怎么办？如何自动生成
3.3.2 IDEA快速构建聚合与继承工程，分模块项目
其实对于聚合和继承工程的创建，IDEA已经能帮助我们快速构建，具体的实现步骤为:
步骤1:创建一个Maven项目
创建一个空的Maven项目，可以将项目中的src目录删除掉，这个项目作为聚合工程和父工程。
步骤2:创建子项目
该项目可以被聚合工程管理，同时会继承父工程。
创建成功后，maven_parent即是聚合工程又是父工程，maven_web中也有parent标签，继承的就是maven_parent,对于难以配置的内容都自动生成。
4，属性
在这一章节内容中，我们将学习两个内容，分别是
- 属性
- 版本管理
属性中会继续解决分模块开发项目存在的问题，版本管理主要是认识下当前主流的版本定义方式。
4.1 属性
4.1.1 问题分析
存在的问题：
前面我们已经在父工程中的dependencyManagement标签中对项目中所使用的jar包版本进行了统一的管理，但是如果在标签中存在多个相同Spring版本号，如下图:
更新Spring的版本就会很麻烦，更改时容易出现遗漏，如何统一配置？
解决思路：在父工程声明一个变量，在其他地方使用该变量，当变量的值发生变化后，所有使用变量的地方，就会跟着修改。
4.1.2 解决步骤
步骤1:父工程中定义属性，定义版本号
<properties>
<spring.version>5.2.10.RELEASEspring.version>
<junit.version>4.12junit.version>
<mybatis-spring.version>1.3.0mybatis-spring.version>
properties>
步骤2:修改依赖的version 为 ${xxx.version} 引用值
<dependency>
<groupId>org.springframeworkgroupId>
<artifactId>spring-coreartifactId>
<version>${spring.version}version>
dependency>
<dependency>
<groupId>org.springframeworkgroupId>
<artifactId>spring-webmvcartifactId>
<version>${spring.version}version>
dependency>
<dependency>
<groupId>org.springframeworkgroupId>
<artifactId>spring-jdbcartifactId>
<version>${spring.version}version>
dependency>
更新父工程中properties标签中所维护的jar包版本，所有子项目中的版本也就跟着更新。实现对项目中所有jar包的版本进行统一维护
4.2 配置文件加载属性
通过Maven来集中管理Maven中依赖jar包的版本。
Maven对于属性的管理范围能更大些，比如我们之前项目中的jdbc.properties，这个配置文件中的属性，能不能也来让Maven进行管理呢?
答案是肯定的，具体的实现步骤为:
步骤1:父工程定义属性（配置文件中的属性）
<properties>
<jdbc.url>jdbc:mysql://127.1.1.1:3306/ssm_dbjdbc.url>
properties>
步骤2:jdbc.properties文件中引用属性
在jdbc.properties，将jdbc.url的值直接获取Maven配置的属性
jdbc.driver=com.mysql.jdbc.Driver
jdbc.url=${jdbc.url}
jdbc.username=root
jdbc.password=root
步骤3:设置maven过滤文件范围
Maven在默认情况下是从当前项目的src\main\resources下读取文件进行打包。现在我们需要打包的资源文件是在maven_02_ssm下,需要我们通过配置来指定下具体的资源目录。
<build>
<resources>
<resource>
<directory>../maven_02_ssm/src/main/resourcesdirectory>
<filtering>truefiltering>
resource>
resources>
build>
**说明:**directory路径前要添加../的原因是maven_02_ssm相对于父工程的pom.xml路径是在其上一层的目录中，所以需要添加。
修改完后，注意maven_02_ssm项目的resources目录就多了该配置文件，如下:
步骤4:测试是否生效
如果有多个项目需要配置，该如何实现呢?
方式一:配置多个资源目录，并设置能够解析${} （繁琐）
<build>
<resources>
<resource>
<directory>../maven_02_ssm/src/main/resourcesdirectory>
<filtering>truefiltering>
resource>
<resource>
<directory>../maven_03_pojo/src/main/resourcesdirectory>
<filtering>truefiltering>
resource>
...
resources>
build>
可以配，但是如果项目够多的话，这个配置也是比较繁琐
方式二: ${project.basedir}表示当前项目所在目录
<build>
<resources>
<resource>
<directory>${project.basedir}/src/main/resourcesdirectory>
<filtering>truefiltering>
resource>
resources>
build>
并且在配置maven打包war时，忽略web.xml检查
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.pluginsgroupId>
<artifactId>maven-war-pluginartifactId>
<version>3.2.3version>
<configuration>
<failOnMissingWebXml>falsefailOnMissingWebXml>
configuration>
plugin>
plugins>
build>
上面我们所使用的都是Maven的自定义属性，除了${project.basedir},它属于Maven的内置系统属性。
在Maven中的属性分为:
- 自定义属性（常用）
- 内置属性
- Setting属性
- Java系统属性
- 环境变量属性
具体如何查看这些属性:
在cmd命令行中输入mvn help:system
具体使用，就是使用 ${key}来获取，key为等号左边的，值为等号右边的，比如获取属性值，对应的写法为 ${java.runtime.name}。
4.3 版本管理
版本管理中有两个单词，SNAPSHOT和RELEASE，它们所代表的含义是什么呢?
- SNAPSHOT（快照版本）
- 项目开发过程中临时输出的版本，称为快照版本
- 快照版本会随着开发的进展不断更新
- RELEASE（发布版本）
- 项目开发到一定阶段里程碑后，向团队外部发布较为稳定的版本，这种版本所对应的构件文件是稳定的
- 即便进行功能的后续开发，也不会改变当前发布版本内容，这种版本称为发布版本
除了上面的工程版本，我们还经常能看到一些发布版本:
- alpha版:内测版，bug多不稳定内部版本不断添加新功能
- beta版:公测版，不稳定(比alpha稳定些)，bug相对较多不断添加新功能
- 纯数字版
对于这些版本，大家只需要简单认识下即可。
5，多环境配置与应用：生产、开发、测试
5.1 多环境开发：maven提供配置多种环境的设定
- 开发人员在自己的开发环境进行开发，
- 当开发完成后，需要把开发的功能部署到测试环境供测试人员进行测试使用，
- 等测试人员测试通过后，我们会将项目部署到生成环境上线使用。
这个时候就有一个问题是，不同环境的配置是不相同的，如不可能让三个环境都用一个数据库，所以就会有三个数据库的url配置，
- 我们在项目中如何配置? --开发环境
- 要想实现不同环境之间如何实现配置切换呢? --设定是否为默认启动环境–
maven提供配置多种环境的设定，帮助开发者在使用过程中快速切换环境。具体实现步骤:
步骤1:父工程配置多个环境,并指定默认激活环境
<profiles>
<profile>
<id>env_depid>
<properties>
<jdbc.url>jdbc:mysql://127.1.1.1:3306/ssm_dbjdbc.url>
properties>
<activation>
<activeByDefault>trueactiveByDefault>
activation>
profile>
<profile>
<id>env_proid>
<properties>
<jdbc.url>jdbc:mysql://127.2.2.2:3306/ssm_dbjdbc.url>
properties>
profile>
<profile>
<id>env_testid>
<properties>
<jdbc.url>jdbc:mysql://127.3.3.3:3306/ssm_dbjdbc.url>
properties>
profile>
profiles>
方式一:配置中切换默认环境为生产环境
<profiles>
<profile>
<id>env_depid>
<properties>
<jdbc.url>jdbc:mysql://127.1.1.1:3306/ssm_dbjdbc.url>
properties>
profile>
<profile>
<id>env_proid>
<properties>
<jdbc.url>jdbc:mysql://127.2.2.2:3306/ssm_dbjdbc.url>
properties>
<activation>
<activeByDefault>trueactiveByDefault>
activation>
profile>
<profile>
<id>env_testid>
<properties>
<jdbc.url>jdbc:mysql://127.3.3.3:3306/ssm_dbjdbc.url>
properties>
profile>
profiles>
是每次切换都是需要手动修改，如何来实现在不改变代码的前提下完成环境的切换呢?
方式二:命令行实现环境切换
mvn install -P 环境id
对于多环境切换只需要两步即可:
-
父工程中定义多环境
-
使用多环境(构建过程)
mvn 指令 -P 环境定义ID[环境定义中获取]
5.2 跳过测试
前面在执行install指令的时候，Maven都会按照顺序从上往下依次执行，每次都会执行test,
对于test来说有它存在的意义，
- 可以确保每次打包或者安装的时候，程序的正确性，但当程序未改动时测试会被再次执行，就有点耗费时间了。
- 功能开发过程中有部分模块还没有开发完毕，测试无法通过，但是想要把其中某一部分进行快速打包，此时由于测试环境失败就会导致打包失败。
遇到上面这些情况的时候，我们就想跳过测试执行下面的构建命令，具体实现方式有很多：
方式一:IDEA工具实现跳过测试（暴力跳过所有测试）
图中的按钮为Toggle 'Skip Tests' Mode,在测试与不测试之间进行切换。
点击一下，出现测试画横线的图片test ,说明测试已经被关闭，再次点击就会恢复。
方式二:配置插件实现跳过测试（精细控制）
在父工程中的pom.xml中添加测试插件配置
<build>
<plugins>
<plugin>
<artifactId>maven-surefire-pluginartifactId>
<version>2.12.4version>
<configuration>
<skipTests>falseskipTests>
<excludes>
<exclude>**/BookServiceTest.javaexclude>
excludes>
configuration>
plugin>
plugins>
build>
skipTests:如果为true，则跳过所有测试，如果为false，则不跳过测试
excludes：哪些测试类不参与测试，即排除，针对skipTests为false来设置的
includes: 哪些测试类要参与测试，即包含,针对skipTests为true来设置的
方式三:命令行跳过测试
使用Maven的命令行，mvn 指令 -D skipTests
注意事项:
- 执行的项目构建指令必须包含测试生命周期，否则无效果。例如执行compile生命周期，不经过test生命周期。
- 该命令可以不借助IDEA，直接使用cmd命令行进行跳过测试，需要注意的是cmd要在pom.xml所在目录下进行执行。
6，私服
6.1 私服简介
团队开发现状分析: 多人开发同一个项目的不同模块，需要相互调用。如果直接拷贝对方的jar包，会造成jar包管理混乱容器出错。且Maven的中央仓库不允许私人上传自己的jar包。
解决思路：自己搭建一个类似于中央仓库的东西，把自己的内容上传上去，其他人就可以从上面下载jar包使用
概念：
- 私服:公司内部搭建的用于存储Maven资源的服务器
- 私服是一台独立的服务器，用于解决团队内部的资源共享与资源同步问题
- 远程仓库:Maven开发团队维护的用于存储Maven资源的服务器
搭建Maven私服的方式：
- Nexus
- Sonatype公司的一款maven私服产品
- 下载地址：https://help.sonatype.com/repomanager3/download
6.2 私服安装
步骤1:下载解压
将资料\latest-win64.zip解压到一个空目录下。
步骤2:启动Nexus
使用cmd进入到解压目录下的nexus-3.30.1-01\bin,执行如下命令:
nexus.exe /run nexus
看到Started Sonatype Nexus Oss，说明启动成功。
步骤3:浏览器访问
访问地址为:http://localhost:8081
步骤4:首次登录重置密码
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aDFtsHBz-1658710617208)(assets/1630988983159.png)]
输入用户名和密码进行登录，登录成功后——点击下一步，需要重新输入新密码，为了和后面的保持一致，密码修改为admin——设置是否运行匿名访问——点击完成
至此私服就已经安装成功。如果要想修改一些基础配置信息，可以使用:
- 修改基础配置信息
- 安装路径下etc目录中nexus-default.properties文件保存有nexus基础配置信息，例如默认访问端口。
- 修改服务器运行配置信息
- 安装路径下bin目录中nexus.vmoptions文件保存有nexus服务器启动对应的配置信息，例如默认占用内存空间。
6.3 私服仓库分类
私服资源操作流程分析:
(1)在没有私服的情况下，我们自己创建的服务都是安装在Maven的本地仓库中
(2)私服中也有仓库，我们要把自己的资源上传到私服，最终也是放在私服的仓库中
(3)其他人要想使用你所上传的资源，就需要从私服的仓库中获取
(4)当我们要使用的资源不是自己写的，是远程中央仓库有的第三方jar包，这个时候就需要从远程中央仓库下载，每个开发者都去远程中央仓库下速度比较慢(中央仓库服务器在国外)
(5)私服就再准备一个仓库，用来专门存储从远程中央仓库下载的第三方jar包，第一次访问没有就会去远程中央仓库下载，下次再访问就直接走私服下载
(6)前面在介绍版本管理的时候提到过有SNAPSHOT和RELEASE，如果把这两类的都放到同一个仓库，比较混乱，所以私服就把这两个种jar包放入不同的仓库
(7)上面我们已经介绍了有三种仓库，一种是存放SNAPSHOT的，一种是存放RELEASE还有一种是存放从远程仓库下载的第三方jar包，那么我们在获取资源的时候要从哪个仓库种获取呢?
(8)为了方便获取，我们将所有的仓库编成一个组，我们只需要访问仓库组去获取资源。
所有私服仓库总共分为三大类:
6.4 本地仓库访问私服配置
- 我们通过IDEA将开发的模块上传到私服，中间是要经过本地Maven的
- 本地Maven需要知道私服的访问地址以及私服访问的用户名和密码
- 私服中的仓库很多，Maven最终要把资源上传到哪个仓库?
- Maven下载的时候，又需要携带用户名和密码到私服上找对应的仓库组进行下载，然后再给IDEA
上面所说的这些内容，我们需要在本地Maven的配置文件settings.xml中进行配置。
步骤1:私服上配置仓库
说明:
第5，6步骤是创建itheima-snapshot仓库
第7，8步骤是创建itheima-release仓库
步骤2:配置本地Maven对私服的访问权限
<servers>
<server>
<id>itheima-snapshotid>
<username>adminusername>
<password>adminpassword>
server>
<server>
<id>itheima-releaseid>
<username>adminusername>
<password>adminpassword>
server>
servers>
步骤3:配置私服的访问路径
<mirrors>
<mirror>
<id>maven-publicid>
<mirrorOf>*mirrorOf>
<url>http://localhost:8081/repository/maven-public/url>
mirror>
mirrors>
为了避免阿里云Maven私服地址的影响，建议先将之前配置的阿里云Maven私服镜像地址注释掉，等练习完后，再将其恢复。
至此本地仓库就能与私服进行交互了。
6.5 私服资源上传与下载
本地仓库与私服已经建立了连接，接下来我们就需要往私服上上传资源和下载资源，具体的实现步骤为:
步骤1:配置工程上传私服的具体位置
<distributionManagement>
<repository>
<id>itheima-releaseid>
<url>http://localhost:8081/repository/itheima-release/url>
repository>
<snapshotRepository>
<id>itheima-snapshotid>
<url>http://localhost:8081/repository/itheima-snapshot/url>
snapshotRepository>
distributionManagement>
步骤2:发布资源到私服
注意:
要发布的项目都需要配置distributionManagement标签，要么在自己的pom.xml中配置，要么在其父项目中配置，然后子项目中继承父项目即可。
发布成功，在私服中就能看到:
现在发布是在itheima-snapshot仓库中，如果想发布到itheima-release仓库中就需要将项目pom.xml中的version修改成RELEASE即可。
如果想删除已经上传的资源，可以在界面上进行删除操作:
如果私服中没有对应的jar，会去中央仓库下载，速度很慢。可以配置让私服去阿里云中下载依赖。
至此私服的搭建就已经完成，相对来说有点麻烦，但是步骤都比较固定，后期大家如果需要的话，就可以参考上面的步骤一步步完成搭建即可。