flatten-maven-plugin插件版本管理原理分析

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>