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

scienario的问题如下（注意：这不是一个跨jar依赖性问题，所以像JarAnalyzer、ClassDep或Tattletale这样的工具不会有帮助。谢谢）

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

每当我需要修改其中一个JAR时，我都会检查相关的源代码以及依赖它的项目的源代码。修改代码、编译、重新打包JAR。到目前为止还不错

问题是：我可能会忘记检查一个依赖项目，因为jar之间的依赖关系可能相当长，并且可能会随着时间而变化。如果发生这种情况，一些JAR可能会“不同步”，我最终会在运行时遇到

NoSuchMethodException

或其他一些类不兼容问题，这正是我想要避免的

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

但是，我确实拥有所有JAR，因此假设可以验证依赖于我修改的代码的JAR，这些JAR在方法签名、类名等方面不一致。但是我如何执行这种检查呢

以前有人遇到过类似的问题吗？如果是，你是如何解决的？任何工具或方法都将不胜感激

如果你需要澄清，请告诉我。谢谢

编辑：

我想澄清一下我的问题

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

考虑这个例子：

您有两个项目：A和B，分别部署为A.jar和B.jar。A取决于B

您希望修改B，所以您要签出它并修改a碰巧依赖的方法签名。您可以编译B并自行运行所有测试，而不会出现任何问题，因为B本身不依赖于任何东西。因此，您很高兴提交您的更改

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

我如何避免这种情况

我正在寻找的工具将检索A.jar，并检查A中的所有依赖项在新修改的B上是否仍然良好。如果我一起重新编译a和B源代码，可能会发生编译错误

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

---

这在我的团队中是一个相当大的问题，因为构建经常中断，因为有人忘记签出（或在Eclipse中打开）正确的项目集。我试图说服人们在提交之前签出源代码并重新编译这些代码，但这不仅需要时间，还需要运行很多命令，所以大多数人觉得这样做太麻烦了。如果该技术不容易实现或自动化，则无法使用。

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

---

我知道-在本地机器上设置（只需启动）很容易，如果it基础架构中没有提供适合您需要的人员，我建议您在本地运行它

有一个解决方案，它允许在依赖关系图中多次包含同一库的不同版本。

我还认为只需设置本地Jenkins是一个最好的主意。您使用什么工具进行构建？也许您可以通过切换到Maven作为构建工具来改善您的情况？在更聪明的情况下，如果您不直接询问，就不要重新编译整个项目。但是，切换到in可能是一件棘手的事情——这几乎不取决于你现在如何组织项目

关于VCS——存在Mercurial/SVN桥——因此您可以使用本地Mercurial进行开发。。。。 检查此链接：

很遗憾，检查签名是不够的。拥有正确的签名并不意味着它会起作用。这一切都是关于签名，而不仅仅是签名。我的意思是，如果库的新版本具有相同的方法签名，但现在以相反的顺序接受ArrayList参数，会发生什么？你迟早会遇到问题的。我想你可能会考虑像IVY或Maven这样的工具：

是的，实现它可能会很痛苦，但一旦你拥有了它，它将永远“保护”你的版本。你不应该碰到这样的问题。但即使是那些构建工具也不是100%准确。处理不兼容库的唯一正确方法，我知道你不会喜欢我的答案，是广泛回归测试。为此，您需要大量的测试工具。它们有很多：从非常基本的单元测试（JUnit）到数据库测试（JDBC代理）以及像SWTBot这样的UI测试框架（取决于你的应用是web应用还是胖客户端）

---

请注意，如果您的项目变得非常庞大，并且您有大量的依赖项，那么您总是不使用那里的所有代码。试图检查所有接口和所有签名太多了。当您的代码使用库代码的30%时，不必全部测试。你需要的是测试你真正使用的东西。这只能通过广泛的回归测试来完成。

我使用IntelliJ，而不是Eclipse，所以我的答案可能太复杂了