publish Bill of Materials POMs

[Roiocam]

Motivation

Resolve: #452

References

• https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms
• https://github.com/spring-projects/spring-boot/blob/v1.5.2.RELEASE/spring-boot-dependencies/pom.xml

[areyouok]

这样做的好处是什么？又多继承了一层，感觉很奇怪

[Roiocam]

这样做的好处是什么？又多继承了一层，感觉很奇怪

对于使用者来说，引入 BOM 的话，避免jetcache传递依赖的库和自身依赖的库使用不同的版本

还有一种情况，当用户依赖的其他库，也有 jetcache 依赖，而且版本不同时，这个时候需要在当前项目固定 jetcache 版本避免出现问题（通过 dependency-management），这个时候一个一个引入包很麻烦，用 BOM 的话，import 一个就足够了，参考：https://github.com/Roiocam/jetcache/blob/08dbafc501b09f550eceff405b6d2191572722a1/samples/spring-sample/pom.xml#L13-L34

对于jetcache而言，分发一个清单给用户，告诉用户，我使用的依赖都是什么版本，你在我这个清单的版本下”一定不会出现问题 “

[areyouok]

对于jetcache而言，分发一个清单给用户，告诉用户，我使用的依赖都是什么版本，你在我这个清单的版本下”一定不会出现问题 “

以前的parent pom有这个作用。

另外还有一些疑问：

• 现在bom和具体的子artifact有某种循环依赖：bom中定义了子artifact的版本，子atifact又最终继承了bom。这样是否会有潜在的问题？
• 在你的代码中，bom和parent这两个pom是否可以合而为一？

[Roiocam]

以前的parent pom有这个作用。

接近, 但是没有子 artifact 的版本，只有第三方的

• 现在bom和具体的子artifact有某种循环依赖：bom中定义了子artifact的版本，子atifact又最终继承了bom。这样是否会有潜在的问题？

看起来是的，不过官方的示例也是这种，暂时没发现其他问题，如果子模块 在 dependencyManagement 里面用 bom 作为 import 反而有点问题，我记得有时候会出现子模块找不到 bom 的错误，需要先本地 install 生成出 bom

• 在你的代码中，bom和parent这两个pom是否可以合而为一？

bom 对外没有自身编译啥需要的东西，但子项目需要，因此有个 parent，用来放编译，checkstyle 之类的，取决于项目需要，不严格要求的可以合成一个

[areyouok]

接近, 但是没有子 artifact 的版本，只有第三方的

这个问题倒不大，现在jetcache的parent和子模块都是一样的。

bom 对外没有自身编译啥需要的东西，但子项目需要，因此有个 parent，用来放编译，checkstyle 之类的，取决于项目需要，不严格要求的可以合成一个

你的意思是，把一些其它的东西从bom里面去掉，从人读的角度来说这个bom的内容更少一些？不过从计算机的角度来说，要下载的东西并不会少，parent和bom作为子模块的爸爸和爷爷要下载下来，继承结构还多了一层。

这一点，别的项目都是怎么做的？

[Roiocam]

接近, 但是没有子 artifact 的版本，只有第三方的

这个问题倒不大，现在jetcache的parent和子模块都是一样的。

但实际用的话，没有子模块的版本，BOM 的意义没有那么大，对用户而言，其他的依赖都可以自己解决，但是有一个 BOM 能声明所有的版本会更方便，不用重复写其他子模块的版本，传递依赖可以传递版本，但是有不同版本的时候就不行。

你的意思是，把一些其它的东西从bom里面去掉，从人读的角度来说这个bom的内容更少一些？不过从计算机的角度来说，要下载的东西并不会少，parent和bom作为子模块的爸爸和爷爷要下载下来，继承结构还多了一层。

这一点，别的项目都是怎么做的？

类似于这个 PR 的方案有：

• spring ：dependencies -> parent -> sub1,sub2,sub3：https://github.com/spring-projects/spring-boot/blob/v2.2.8.RELEASE/spring-boot-project/spring-boot-actuator/pom.xml
• jackson : bom -> base -> core：https://github.com/FasterXML/jackson-core/blob/2.18/pom.xml
• log4j： bom -> log4j(parent) -> sub1,sub2,sub3: https://github.com/apache/logging-log4j2/blob/2.x/log4j-parent/pom.xml

不是这种方案，而是 bom 只记录子身子模块的版本，外部版本由其他人自己决定的有：

• netty：https://github.com/netty/netty/blob/4.1/bom/pom.xml
• r2dbc: https://github.com/r2dbc/r2dbc-bom/blob/main/pom.xml

其他的 grpc java, spring 高版本, micrometer, project reactor，okhttp 是通过 gradle 实现的.

也有自己写 bom 插件的：https://github.com/apache/camel/blob/main/bom/pom.xml

分析下来就是，外部库版本对自身的实现不影响的，没有太大兼容性风险的都是只维护子模块 BOM，否则就是 spring 这种。我觉得 jetcache 也是 spring 这种吧，毕竟 jedis 不同版本的区别太大了，假如只用子模块的 BOM，然后让 spring 来选择依赖，那么如果 spring 版本低了（例如我们是 2.x， jedis 还在 3.x 的版本）就会出现兼容问题，jedis api 不一样了、少类、包名换了。

[areyouok]

ok，我没有问题了。

另外，上次改的jedis相关的内容，你们自己用过了吗，是否需要发布一个版本？