1、概念：
Maven工程之间，A工程继承B工程
- B工程:父工程
- A工程:子工程
本质上是A工程的 pom.xml 中的配置继承了B工程中pom.xml 的配置。
2、作用：
（依赖的信息可以统一在父工程中进行抽取和统一管理，比如说有F这个父工程，A、B、C、D、E这几个子工程，里面都用到了同一个框架spring，那么就要保证统一用到的spring框架版本是相同的版本，甚至说需要统一修改版本的时候也可以在父工程中进行统一的修改，实现一处修改处处生效的效果，那么我们就把版本号放在父工程中进行统一的修改和管理。具体来说，继承主要就是管理我们项目中使用的依赖信息的版本version）
在父工程中统—管理项目中的依赖信息，具体来说是管理依赖信息的版本。
它的背景是:
- 对一个比较大型的项目进行了模块拆分。
- 一个project 下面，创建了很多个module。
- 每一个module都需要配置自己的依赖信息。
它背后的需求是:
- 在每一个module 中各自维护各自的依赖信息很容易发生出入，不易统一管理。
- 使用同一个框架内的不同jar包，它们应该是同一个版本，所以整个项目中使用的框架版本需要统一。
- 使用框架时所需要的jar包组合(或者说依赖信息组合）需要经过长期摸索和反复调试，最终确定一个可用组合。这个耗费很大精力总结出来的方案不应该在新的项目中重新摸索。
通过在父工程中为整个项目维护依赖信息的组合既保证了整个项目使用规范、准确的jar包；又能够将以往的经验沉淀下来，节约时间和精力。
3、举例
比如使用Spring时要求所有Spring自己的jar包版本必须一致。为了能够对这些jar包的版本进行统一管理，我们使用继承这个机制，将所有版本信息统一在父工程中进行管理。
4、操作
4.1创建父工程
创建过程和前面的文章提到的使用命令行窗口进行Maven版的java工程创建一样
工程名称：pro03-maven-parent
父工程创建好之后要打开父工程的pom.xml文件修改父工程的打包方式：
（这里一定要改，否则在下面创建子工程时会报错：
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:3.2.1:generate (default-cli) on project pro03-maven-parent: Unable to add module to the current project as it is not of packaging type 'pom'）
父工程中的依赖就没有用了，可以删掉
只有打包方式为pom的Maven 工程能够管理其他Maven 工程。打包方式为pom 的Maven 工程中不写业务代码，它是专门管理其他 Maven工程的工程。
4.2创建模块工程
模块工程类似于IDEA中的 module，所以需要进入pro03-maven-parent工程的根目录，然后运行mvnarchetype:generate命令来创建模块工程。
假设，我们创建三个模块工程:（从继承的角度来说是父工程和子工程的关系，从聚合的角度来说是总工程和模块工程的关系）
创建好了之后我们再打开父工程的pom.xml文件，会发现新增了这几个标签项
打开任意一个子工程的pom.xml文件，会发现自动生成了parent标签
子工程的groupId 如果和父工程一样，则可以省略
子工程的version 如果和父工程一样，则可以省略
省略 groupId和 version 后，子工程自己的坐标可以只保留artifactId
4.3在父工程中统一管理依赖信息
哪个子工程需要哪个依赖，就在该子工程的pom.xml文件中去配置依赖的坐标即可，可不配置version ，例如子工程pro04-maven-modul需要spring-core，就在其pom.xml文件中配置相应坐标即可
4.4在父工程中修改依赖的版本
首先确认一下新的版本的有无，最好去mvnrepository官网去搜索确认一下，确认有这个版本的话，再去父工程中修改，去父工程中修改之后，所有子工程的版本号会自动修改（所以，采用子工程继承父工程最大的好处就是进行一个版本的管理，若不采用这种机制的话，一个工程一个工程的去修改版本号，很容易造成遗漏）
上面的步骤其实并没有做到一处修改处处生效，那么怎么才能做到一处修改处处生效呢，我们注意一下父工程的pom.xml文件中的properties标签，里面是可以自定义标签的
这样以来，我们只需要修改我们的自定义标签，即可修改所有的引用了自定义标签的version值。当然子工程中同样也是有自定义标签的，用法相同，这里就不再做过多的介绍
