一种工具,用于检测类和方法签名级别上损坏的JAR依赖性

时间:2011-02-21 11:59:20

标签: java jar dependencies

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

我有一个大项目,它被编译成10个或更多jar文件。所有罐子彼此依赖并形成依赖层次结构。

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

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

我能想到的唯一解决方案,即最直接的解决方案是检查所有项目,并重新编译。但这需要时间,特别是如果我每次小改变都重新构建它。我有一个持续集成服务器,可以为我做这个,但它与其他开发人员共享,所以看看构建中断是不是我的选择。

但是,我确实所有的罐子都是假设的,应该可以验证依赖于我修改的代码的罐子在方法签名,类名等方面有不一致但是我怎么能进行这样的检查呢?

之前有没有人遇到过类似的问题?如果是这样,你是如何解决的?任何工具或方法都将受到赞赏。

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

修改

我想澄清一下我的问题。

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

考虑这个例子:

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

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

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

我该如何避免这种情况?

我正在寻找的工具类型将检索A.jar并检查新修改的B上的A中的所有依赖项是否仍然正常。就像潜在的编译错误一样,如果我要一起重新编译A和B源,就会发生错误。

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

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

6 个答案:

答案 0 :(得分:2)

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

我知道Jenkins - 在本地计算机上设置(刚启动)很容易,如果IT基础架构中没有提供符合您需求的人员,我建议在本地运行它。

答案 1 :(得分:2)

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

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

http://maven.apache.org/

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

请注意,如果您的项目变得非常庞大并且您拥有大量依赖项,那么您始终不会使用所有代码。试图检查所有接口和所有签名太多了。当代码使用时,没有必要对所有代码进行测试。你需要的是测试你真正使用的是什么。这只能通过广泛的回归测试来完成。

答案 2 :(得分:1)

我也认为只需设置本地Jenkins就是最好的主意。你用什么工具进行构建?也许你可以通过切换到Maven作为构建工具来改善你的情况?如果你不直接问它,更聪明,不要重新编译完整的项目。但切换到可以是巨大的油漆 - 它几乎不取决于你现在如何组织...

关于VCS-存在Mercurial / SVN网桥 - 因此您可以使用本地Mercurial进行开发.... 点击此链接:https://www.mercurial-scm.org/wiki/WorkingWithSubversion

答案 3 :(得分:1)

我终于在this post找到了一整套答案。感谢大家的帮助!

赏金归于K. Claszen,是最快和最多的投入。

答案 4 :(得分:0)

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

答案 5 :(得分:0)

我使用的是IntelliJ,而不是Eclipse,所以也许我的答案太过IDE了。但是在IntelliJ中,我只是将B中的模块包含到A中,这样当我对A进行更改时,它会在IDE中进行编译时立即中断B.模块可以属于多个项目,因此这不像重复,它只是将IDE中的引用添加到其他项目中的模块。