gpt4 book ai didi

java - 用于检测类和方法签名级别上损坏的 JAR 依赖关系的工具

转载 作者:行者123 更新时间:2023-11-30 05:57:52 26 4
gpt4 key购买 nike

问题场景如下(注意:这不是跨 jar 依赖问题,因此 JarAnalyzer、ClassDep 或 Tattletale 等工具无济于事。谢谢)。

我有一个大项目,它被编译成 10 个或更多 jar 工件。所有 jar 相互依赖并形成依赖层次结构。

每当我需要修改其中一个 jar 时,我都会查看相关源代码以及依赖它的项目的源代码。修改代码,编译,重新打包jar。到目前为止一切顺利。

问题是:我可能会忘记检查依赖项目之一,因为 jar 之间的依赖关系可能会很长,并且可能会随着时间而改变。如果发生这种情况,一些 jar 可能会“不同步”,我最终会在运行时遇到 NoSuchMethodException 或其他一些类不兼容问题,这是我想避免的。 p>

我能想到的唯一解决方案,也是最直接的解决方案,就是检查所有项目,然后重新编译这些项目。但这需要时间,特别是如果我每次微小的更改都重新构建它。我确实有一个持续集成服务器,可以为我做到这一点,但它与其他开发人员共享,因此查看构建是否中断对我来说不是一个选择。

但是,我确实拥有所有 jar,因此假设应该可以验证依赖于我修改的代码的 jar 在方法签名、类名等方面是否不一致。但是我如何执行此类检查?

有人遇到过类似的问题吗?如果是这样,你是如何解决的?任何工具或方法将不胜感激。

如果您需要澄清,请告诉我。谢谢。

编辑:

我想稍微澄清一下我的问题。

此任务的最终目标是检查我所做的更改是否会针对整个项目进行编译。我正在寻找一种工具/技术来帮助我执行此类检查。

考虑这个例子:

您有 2 个项目:A 和 B,分别部署为 A.jar 和 B.jar。 A 依赖于 B。

您希望修改 B,因此您检查它并修改 A 恰好依赖的方法签名。您可以编译 B 并自行运行所有测试,不会有任何问题,因为 B 本身不依赖于任何东西。所以你很高兴地提交你的更改。

几个小时后,整个项目集成失败,因为 A 无法编译!

如何避免这种情况?

我正在寻找的工具会检索 A.jar 并检查 A 中对新修改的 B 的所有依赖关系是否仍然正常。就像如果我一起重新编译 A 和 B 源代码时可能会发生的潜在编译错误。

正如许多人所建议的,另一个解决方案是建立一个本地持续集成系统,该系统可以在本地重新编译整个项目。我不介意这样做,但我想避免在我的工作空间内这样做。另一方面,如果我将所有源 checkout 到另一个临时工作区,那么我需要将本地更改镜像到临时工作区。

这在我的团队中是一个相当大的问题,因为构建经常因为有人忘记 checkout (或在 Eclipse 中打开)正确的项目集而中断。我试图说服人们在提交之前检查源代码并重新编译一堆,但这不仅需要时间,而且需要运行相当多的命令,所以大多数人觉得这样做太麻烦了。如果该技术不简单或不自动化,那么它就无法使用。

最佳答案

如果您不想使用共享的持续集成服务器,您应该在开发人员计算机上设置一个本地服务器,以便在更改时执行重建过程。

我知道Jenkins - 在本地计算机上很容易设置(只需启动),如果 IT 基础设施中没有提供适合您需求的信息,我建议您在本地运行它。

关于java - 用于检测类和方法签名级别上损坏的 JAR 依赖关系的工具,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/5065651/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com