用于检测类和方法签名级别上破碎的JAR依赖关系的工具

Question

问题科学如下(注意:这不是一个跨jar依赖问题，所以像JarAnalyzer、ClassDep或Tattletale这样的工具不会有帮助。谢谢)。

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

每当我需要修改一个jars时，我都会查看相关的源代码和依赖它的项目的源代码。修改代码，编译，重新打包jars。到目前一切尚好。

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

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

然而，我确实拥有所有的jars，所以假设应该能够验证依赖于我修改的代码的jars在方法签名、类名等方面的不一致性。但是我如何执行这样的检查呢？

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

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

编辑

我想澄清一下我的问题。

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

考虑一下这个例子：

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

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

几个小时内，由于无法编译A，整个项目集成失败了！

我怎么才能避免这种情况？

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

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

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

Answer 1

我终于在这个职位找到了一个装满答案的宝箱。谢谢大家的帮助！

赏金付给K. Claszen，以获得最快和最多的投入。

Answer 2

如果不想使用共享的连续集成服务器，则应该在开发人员计算机上设置本地服务器，在该机器上执行更改后的重建过程。

我知道詹金斯 --在本地机器上安装(只是启动)很容易，如果it基础结构中没有适合您需要的人，我会建议在本地运行它。

Answer 3

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

http://ant.apache.org/ivy/

http://maven.apache.org/

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

请注意，如果您的项目变得非常庞大，并且您有大量的依赖项，则始终没有使用所有的代码。尝试检查所有接口和所有签名都太过分了。当您的代码使用30 %的库代码时，没有必要全部测试它。你需要的是测试你真正使用的东西。只有通过广泛的回归测试才能做到这一点。