maven父子模块两种种搭建方式简记
为什么需要父子模块
使用maven构建父子模块，便于我们项目依赖和版本的管理，以下便是笔者整理的两种maven父子模块搭建方式。
第1种-子模块与父模块同级(不常用)
这种搭建方式由于可读性比较差，所以搭建方式比较不常见，多出现在一些比较老旧，且模块划分多的项目中。话不多说，以下便是笔者的创建过程。
创建空项目
首先我们创建一个空的项目，如下图所示:
完成后我们输入项目的名称和文件存放路径，点击下一步。
这里要求我们引入模块，我们直接点击取消。
自此我们就得到了一个空的项目。
创建父模块
我们对着这个项目点击new创建父模块。
然后我们选择创建的项目为maven工程，点击下一步。
设置当前maven项目GAV坐标，完成后点击下一步。
然后我们将存放位置设置为我们上一步所创建的项目的位置下。
自此IDEA出现下面这种日式，我们通常选择“Enable Auto-Import”自动导入依赖即可。
重点步骤，为了让我们创建的这个项目变为父模块，我们必须进行如下操作:
- 父工程的 packaging 标签的文本内容必须设置为 pom。
pom
- 删除src文件夹，让这个项目完全作为父模块管理maven父子工程。
创建子模块
同样的我们点击创建模块
选择为maven项目
然后我们可以，设置 module 项目基础信息，注意parent指定为上步创建的父id，每个选项具体含义为
Add as module to：选择将创建的模块添加哪个模块
Parent：选择模块的父工程
GroupId：选择父工程后，默认继承父工程的 GroupId 值
ArtifactId：模块的项目名称
Version：选择父工程后，默认继承父工程的 Version 值
最后我们设置项目位置，可以看到和父模块同级。
自此我们的子模块也创建完成了,可以看到其parent指向了我们的父模块。
通用配置
为了统一我们不妨。设置父工程 编译级别，通过在 File -> Settings -> Build, Execution, Deployment -> Compiler -> Java Compiler 查看，我们默认的编译级别为1.5。
然后在父pom中通过即可完成编译级别改为1.8，如图所示
完成后查看之前的设置步骤，编译级别变为1.8了
依赖管理
执行后效果：在父工程dependencies标签中添加MySQL依赖，子模块会无条件继承父工程所有依赖。
先来看看我们当前的项目情况，没有添加任何的依赖。
然后我们在父工程添加mysql依赖。
可以看到父子工程都导入了mysql依赖
以上写做法，子模块会无条件继承父工程的所有依赖，导致的问题是，本不需要的继承的依赖也会被继承，这就大大增加了项目模块最终打包的大小，也可能未上线埋下了隐患。
也就是说，父工程管理的是所有项目模块的依赖，而不是某一个项目模块的依赖，所以某一个项目模块不需要继承父工程中的所有依赖，这就需要子项目模块向父工程声明需要的依赖即可（声明式依赖）。而此时，父工程实际只需要管理依赖的版本号即可。
实现方式
父工程添加 dependencyManagement
父工程 父工程加 添加 dependencyManagement 标签管理依赖
完成后结果查看，可以看到父子模块都没有显示引入依赖了。
然后我们对父工程加 添加 properties 管理版本号，在 properties 标签中，可以自定义标签名称来管理依赖的版本号，通常自定义的标签名称由“项目名称”+version 英文单词构成。被管理的依赖版本号由“${算定标签名称}”来代替。
由于父工程管理依赖的版本号，那么子模块要想继承依赖，只能通过声明式来添加依赖，实际上，子模块中的依赖是继承父工程依赖的版本号；如果子模块已定义依赖版本号，那么以子模块定义的版本号为准。
可以看到最终子模块会根据父模块的依赖以及配置的版本号引入需要的依赖。
第2种父子工程-分层搭建(常见)
这种方式是笔者比较常用的一种方式，所以为了让创建步骤更有带入感，笔者准备了一个近期要做的项目进行演示。
以下便是笔者的创建步骤。
创建一个maven项目
如下图，这个项目就是笔者新创建的一个maven项目，可以看到这个项目当前就是一个普通的maven项目，还没构建成maven工程。
创建子模块
首先点击new module创建一个子模块
这里直接选择maven项目点击下一步
输入项目名称后直接点击下一步
项目位置选择我们所创建的目录的根目录即可
此时，我们的子模块就创建好了
可以看到父pom直接出现packaging以及引入了module
调整项目
最后为了让这个项目变为maven父子工程，我们还是要将src文件夹删除。最终我们的项目变成这样，如果我们还需要添加子模块，同理创建即可。
常见问题
多环境配置是什么，有什么作用
日常开发过程中，我们的应用需要在多个环境下进行部署测试。例如在日常开发时，我们希望每个依赖的应用都是使用快照版，然后发布出去时希望应用的依赖是发布版。如下图，我们希望同一套应用可以根据使用环境的不同，将应用设置为不同的版本
对此我们不妨编写一个示例演示一下，首先我们创建一个maven父子项目，结构如下图所示：
我们希望在开发环境子模块son所依赖的junit是4.1.2版本。到了生产环境junit是4.1.3。对此我们就需要对同一个依赖配置不同版本。
所以我们的首先需要在父pom依赖管理配置中加上junit
dependencyManagement>
junit
junit
test
重点步骤来了，若为开发环境，junit配置为4.1.2，配置内容如下所示，id设置为dev，声明一个junit-version标签，指定配置版本为4.1.2，意为开发环境junit版本为4.1.2
dev
[1.8,)
false
true
4.12
release
true
false
同理生产环境配置如下
1.8
UTF-8
1.8
1.8
false
false
true
true
true
false
4.13
完整的父pom配置以及注释
4.0.0
com.zsy.maven
testDev
1.0-SNAPSHOT
son
pom
dev
[1.8,)
false
true
4.12
release
true
false
1.8
UTF-8
1.8
1.8
false
false
true
true
true
false
4.13
junit
junit
test
然后我们的son模块只需引入junit依赖即可，配置如下
junit
junit
${junit.version}
test
这时候我们就会看到我们开发环境的junit版本为4.1.2
多环境配置工作流程
不难从maven设计者的角度考虑到多环境配置的工作流程，当我们环境配置了多个环境时，难免会出现环境依赖配置不一致的问题。例如我们开发环境没有配置junit版本，maven意识到这个问题，他就会去生产环境的版本中读取配置，这就是为什么笔者在上文配置的过程中生产环境配置没有加id的原因
可以看到笔者将开发环境junit版本注释后，junit版本就会变成生产环境的4.1.3
遇到过的问题与解决思路
之所以笔者会提出上述的工作流程，正是因为开发时遇到了生产环境无法导入依赖的问题，因为前人配置依赖版本时，将版本号标签配置错误，导致导入依赖时用了生产环境的配置进而出现意外的错误。沿用上文的例子，可能就是将开发环境的junit.version写成了junit-version,如下图所示
所以我们每当遇到这种环境问题时，需要分析每个管理工具的工作流程，从工作流程角度推算出可能会出现问题的地方，以及这种粗心的错误，我们可能需要使用cv大法进行文本比对。例如笔者上文所出现的问题，我们首先就需要从maven导入依赖流程中推断问题所在，就上文的现象，我们从maven工作流程可以推断出问题出现的地方可能是:
1. maven开发环境配置版本错误
2. maven开发环境配置没有配置对应版本的配置信息
3. 如下文所示，标签配置错误，读取了默认配置