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

Question

ore.spongepowered.org是一个托管Minecraft插件的网站。

这些插件依赖于一个名为SpongeAPI的依赖项来运行。

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

E.g。针对API版本5发布了一个插件jar。

API 5.1（semver）发布，它只包含附加内容。只要semver被强制执行，我们就知道由于版本控制惯例，该插件可能会有效。

API 6发布了，它是一个半主要版本，但jar是针对API5构建的，插件有可能仍然兼容，但不能保证。我们如何测试（使用工具）插件是否具有对已删除的代码的任何引用，或者是否已从API 5更改其签名 - ＆gt; API 6？

这很有价值，因为我们可以在使用可能不兼容的组合时警告人们。

注意：我们控制了Library SpongeAPI，而不是社区制作的插件。

Answer 1

传统方法是使用自动构建和持续集成工具（如Jenkins，Bitbucket Pipelines，Gitlab-CI等）构建系统（我假设您已经使用Maven或Gradle已经在您的问题中标记了它们）。

如果更改（更新的依赖项）改变了方法签名或其他重构，那么构建将失败。

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

最后，您可能希望查看新的Java 9模块系统。它在采用方面仍然有点落后，但它可能为您所寻找的内容提供替代解决方案，特别是如果您也控制了依赖关系。

Answer 2

即使依赖关系树中的每个组件都完全符合SemVer标准，您仍然需要带外（与SemVer相关）信息来关闭瞬态依赖关系。一般的依赖图和特别是钻石点依赖问题是已知的难题。测试可能会带来一些小但非常昂贵的缺点，但对于在具有数百或数千个组件的服务器上运行的任何非平凡产品来说通常都是禁止的。

您可以做的最好的事情就是将应用程序周围的环境容纳在一起，并仅测试其中相关组件的有趣组合，仅释放那些通过您产品的整个测试套件的组合。然后你可以说＆＃34;这是一个预先配置了我们的功能X的盒子，我们不声明与任何其他产品或组件版本组合的兼容性＆＃34;。特定于应用的VM在将问题空间减少到经济上可管理的表面方面是最好的。甚至像app容器这样的漏洞也可以帮助驯服这只老虎。