我报名参加金石计划1期挑战——瓜分10万奖池，这是我的第1篇文章，点击查看活动详情
1.写在前面
在目前一些java开发的过程中，大部分的项目，应该占了大部分，都是使用maven进行项目的依赖管理的吧？也有一些可能使用gradle，个人用得也不是很多，这里就不多展开描述了。
在使用maven进行管理得时候，可能会出现下面这些问题：
随着项目的功能不断迭代，项目越做越大，那系统架构师，这个时候，就开始干活了，对项目的框架进行调整，例如：对公共部分进行封装，利用一些开闭原则，依赖倒置原则等，对框架大大阔斧的改造。
最终的结果，可能会出现多个共性的模块，例如下面这样：
由上可见，一般来说，好的框架，可能一些common包，就已经是封装成了好几个模块。（例如上面的）
对于这些公共的依赖，当我们进行修改的时候，只需要改对应的模块代码即可。
但是会出现这样的一个问题，每个common公共依赖的版本号，可能会不一样：可能common-core是1.0，common-datascope是1.1，common-datasource是1.2等等，这样就导致项目的依赖管理，会变得比较混乱。
当然，你都设置成一样的版本号，不也能解决这个问题嘛？
好嘛，好嘛，就算你设置成一样的版本号，也会出现这样的一个问题，当我们需要发布一个新的版本，每个common公共依赖的版本号，也得更新一次。
那不就是很麻烦了嘛？还得手动去改一次版本号。
当然，有些人这时候会抬杠，我更新版本的时候，common公共依赖版本号不更新，不行嘛？
怎么说呢？这肯定也是可以的，但是作为一个好的程序员，版本管理，我们还是得抓一抓。没个版本管理，别人都不知道，你有发过新的版本？都不知道你更新了些啥？
好了，对于上面的这些问题，不知道大家伙有无听懂？估计都能懂吧，不懂再读多几遍啦！！！
OK，对于上面的问题，我们有无便捷的方式处理呢？
对于这样的一个问题，我们都能想到，common公共依赖，我都用一个公共的parent的pom配置一个版本号，然后common的模块，都使用这样公共的版本号配置。
例如下面：
例如，上面这样：
commons和common-core。
commons父项目，定义一个revision公共的版本号占位符。
common-core子项目，直接使用commons父项目定义的revision版本号。
这样的解析，应该都很清晰了吧。
好了，这样做的好处就是，我一改commons父项目的revision占位符，所有的子项目，都能直接应用到。
那就做到了一改全改的效果了，是不是一个很清晰的做法呢？
好了，想法是很简单啦，那要如何实现呢？这个时候，flatten-maven-plugin插件就跳出来了。
flatten-maven-plugin: 哥们能做到这个效果喔，用我吧！！！
好嘛，好嘛，那我们就来使用一下flatten-maven-plugin插件，上菜咯！！！
2.插件使用
- common父项目
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>flatten-maven-plugin</artifactId>
<version>1.1.0</version>
<configuration>
<updatePomFile>true</updatePomFile>
<flattenMode>resolveCiFriendliesOnly</flattenMode>
</configuration>
<executions>
<execution>
<id>flatten</id>
<phase>process-resources</phase>
<goals>
<goal>flatten</goal>
</goals>
</execution>
<execution>
<id>flatten.clean</id>
<phase>clean</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
复制代码定义使用
flatten-maven-plugin插件。
额，好像就这么定义就完事了？
好吧确实如此，就是这么的简单！！！
上面的插件定义好之后，我们在进行项目的打包，就可以帮我们替换revision公共的版本号
执行：mvn install 或者 mvn package
3.原理分析
看到这里，我们来看一下这个插件的原理是什么？
可能小伙伴，都多多少少的带有这样的疑问，它是如何做到的呢？
当我们打包完成后，我们看一下项目的目录，可以看到多了一个.flattened-pom.xml文件。
我们看一下.flattened-pom.xml文件，对比一下之前的pom.xml文件，如下图所示：
由上图，可以看到，
${revision}已经被替换成真实的版本号了。
那这样，我们就能猜到这个插件的原理了吧：
flatten-maven-plugin插件，通过将pom.xml文件里面的${revision}替换成真实的版本号，然后生成.flattened-pom.xml文件，然后mvn install或mvn package就以.flattened-pom.xml文件进行打包。
嗯嗯，我也是这么想的，可能不对，大家轻点喷！！！
4.问题处理
在我们看懂了3.原理分析后，其实我们就能处理相关的问题了。
这里，分享一个问题：${revision}无法被替换成真实的版本号。
有时候，会出现
.flattened-pom.xml文件，${revision}无法被替换成真实的版本号
出现这样的问题，就是flatten-maven-plugin插件，不起作用导致的。
这里，我通过百度，很快就找到了相关的答案：
flatten-maven-plugin插件需要的maven版本，要3.5以上。
哎，好巧不巧，我idea的版本是2019，自带的maven是3.3.9
那这里，我们就得重新安装一个maven，3.6.0的。
这里也不能安装太高，因为我的idea是2019比较旧，太高会不行。不然会出现：idea maven 版本不兼容
好了，以上就是flatten-maven-plugin插件使用、版本管理原理分析和相关问题解决的分享了。
可能内容有点短，但都是干货喔！！！
个人理解，可能也不够全面，班门弄斧了。
如果觉得有收获的，帮忙点赞、评论、收藏一下呗！！！