flatten-maven-plugin插件使用、版本管理原理分析和相关问题解决

我报名参加金石计划1期挑战——瓜分10万奖池，这是我的第1篇文章，点击查看活动详情

1.写在前面

在目前一些java开发的过程中，大部分的项目，应该占了大部分，都是使用maven进行项目的依赖管理的吧？也有一些可能使用gradle，个人用得也不是很多，这里就不多展开描述了。

在使用maven进行管理得时候，可能会出现下面这些问题：

随着项目的功能不断迭代，项目越做越大，那系统架构师，这个时候，就开始干活了，对项目的框架进行调整，例如：对公共部分进行封装，利用一些开闭原则，依赖倒置原则等，对框架大大阔斧的改造。

最终的结果，可能会出现多个共性的模块，例如下面这样：

由上可见，一般来说，好的框架，可能一些common包，就已经是封装成了好几个模块。（例如上面的）

对于这些公共的依赖，当我们进行修改的时候，只需要改对应的模块代码即可。

但是会出现这样的一个问题，每个common公共依赖的版本号，可能会不一样：可能common-core是1.0，common-datascope是1.1，common-datasource是1.2等等，这样就导致项目的依赖管理，会变得比较混乱。

当然，你都设置成一样的版本号，不也能解决这个问题嘛？

1663055463248(1).jpg

好嘛，好嘛，就算你设置成一样的版本号，也会出现这样的一个问题，当我们需要发布一个新的版本，每个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>