maven deploy plugin_maven 版本管理与 flatten-maven-plugin

参考学习：【maven插件】flatten-maven-plugin ： 处理版本占位符

研究的maven版本管理的原因是觉得有些项目管理方式感觉不太科学，比如在微服务系统当中，有一种做法是所有服务都依赖一个包，里面进行版本管理。可是里面的每个服务的version版本管理却是单独使用一个版本号。快速迭代的版本中，通常是要不断地切换version，那么当服务众多的时候，修改起版本来就很麻烦。

比如 SimonLee/xkcoding_spring-boot-demo 这个大哥写的demo就很不错，我会来参考学习。然后看它的版本管理方式：

最外层的parent这里写死了版本

然后里面的单独的dubbo系统里也写死了版本。

也就是全部都写死了版本。（大哥他不需要更新，所以这些写没啥毛病）

然后我们在版本快速迭代中，也这样使用的话，通常做法就是全局搜索替换版本号，这样就显得很捞，感觉不太科学。

然后就有了revision的占位符统一管理。

Maven官方文档说：自 Maven 3.5.0-beta-1 开始，可以使用 ${revision}, ${sha1} and/or ${changelist} 这样的变量作为版本占位符

这种写法也可以在springboot源码中有看到。

https://github.com/spring-projects/spring-boot/blob/2.0.x/pom.xml

然后你可以看到里面其它子系统都是使用这种方式进行管理的。

然后拿个具体的demo来试试，这是我以前学习dubbo从网上复制改编的例子

原来的结构是这样的

父类传递依赖。然后里面也是直接写死了版本，然后我使用revision来修改

这个是父pom

这个是子类pom.

然后编译运行也是没什么问题的。

然后install、deploy的时候就出现问题了。打出来的jar包的pom文件里还是原来的revision变量，即到maven仓库中查看

这里识别不出版本号，这样就可能导致引用方不能识别你的jar包。

然后这个时候就需要一个插件来改善一下了

也就是在父pom中引入 flatten-maven-plugin 插件。

然后install之后，这个时候再观察项目结构

发现多了pom文件。

点开一看

发现这是把占位符替换掉的完整的pom文件。

然后再比对一下两者的控制台输出

发现使用插件之后，发现它是把这个新的pom打到jar包里。也就是说，这个插件的作用就是在install或者deploy的时候，生成一个新的替换占位符的pom文件，也就是帮你替换了这些变量，接着把新的pom文件打入到jar包里。

然后此时再来看maven仓库的内容

发现是新的pom文件。这样其实就和之前的没什么差别了。

我install的是父工程，直接打子类会出问题，这些就是maven基础了，不多赘述。

然后，这样就可以比较好地解决了快速版本替换时的修改问题了。

这是我接触到的一种方式，应该还有其它更好的管理方式，欢迎交流讨论~