如何确定升级依赖项是否会破坏jar文件？

Question

ore.spongepowered.org是一个托管“我的世界”插件的网站。

这些插件依赖于名为SpongeAPI的依赖项才能运行。

给定一个已经上传到我们的服务的jar文件，并且有元数据将其与给定的(半) SpongeAPI依赖相关联，我们如何确定SpongeAPI中是否存在影响给定插件的二进制不兼容的更改？

例如，为API版本5发布了一个插件jar。

API 5.1 (semver)发布，它只包含新增内容。只要semver被强制执行，我们就知道由于版本控制约定，插件很可能会工作。

API6发布了，这是一个半个主要的版本，但jar是基于API5构建的，插件仍然可能是兼容的，但不能保证。我们如何测试(使用工具)插件是否引用了从API5 -> API6中删除的代码或更改了它的签名？

知道这一点是有价值的，因为当人们使用潜在的不兼容组合时，我们可以警告他们。

注意:我们控制的是库SpongeAPI，而不是社区制作的插件。

Answer 1

传统的方法是使用自动构建和持续集成工具来构建系统，如Jenkins、Bitbucket Pipeline、Gitlab-CI等(我假设您使用的是Maven或Gradle，因为您已经在问题中对它们进行了标记)。

如果更改(对较新的依赖项)更改了方法签名或其他重构，则构建将失败。

此外，您还应该进行单元测试，以确保您的功能按预期工作。如果底层库的基本行为发生了变化，从而影响了您的函数，那么您也可以检测到这一点。这将帮助您捕获功能更改，而不仅仅是编译问题。

最后，您可能想看看新的Java9模块系统。它在采用方面仍然有点落后，但它可能为您正在寻找的东西提供另一种解决方案，特别是如果您也控制了依赖关系的话。

Answer 2

即使您的依赖关系树中的每个组件都完全符合SemVer标准，您仍然需要带外(与SemVer相关)信息来关闭瞬时依赖关系。一般来说，依赖图和菱形点依赖问题是已知的困难问题。测试可以给它带来很小但非常昂贵的凹痕，但对于在具有数百或数千个组件的服务器上运行的任何非平凡产品来说，通常是禁止的。

您能做的最好的事情就是将应用程序周围的环境容器化，只测试其中相关组件的有趣组合，只发布那些通过整个产品测试套件的组合。然后你可以说“这是一个预先配置了functional X的盒子，我们没有声称与任何其他产品或组件版本的组合兼容”。特定于应用程序的虚拟机在将问题空间减少到经济上可管理的表面方面是最好的。即使是像应用程序容器这样漏洞百出的环境也可以帮助驯服这只老虎。