找出 Eclipse 项目中引用的 jar 的所有冲突包/类
我目前正在处理一个巨大的 Eclipse 项目(不是我写的)。该项目不使用任何依赖管理工具。它引用了数百个 JAR。
其中一些 JAR 包含相同的包(和类),但版本不同。目前,解决冲突的方法是在 Order&Export
(在项目属性中)中手动(随机!)重新排序这些 JAR。
这已经做了很长时间了,现在有很多具有不同供应商/版本/产品线的包/类。
重新排序会导致项目的某些部分失败,而其他部分开始工作,反之亦然。 奇怪的是,许多命令不会导致构建错误,而只会导致运行时错误。
这个混乱可以通过一个工具来解决吗,该工具会建议依赖 JAR 的某些自动顺序?
I am currently dealing with a huge Eclipse project (not written by me). This project doesn't use any dependency management tools. It references hundreds of JARs.
Some of these JARs contain same packages (and classes), but in different versions. Currently, resolving conflicts works by manually (and randomly!) reordering these JARs in Order&Export
(in Project Properties).
This was done for a long time now, and there are now lots of packages/classes with different vendors/versions/product-lines.
Reordering causes some parts of the project to fail while other parts start working, and oppositely.
Strangely, lots of orders do not cause build errors, but only runtime errors.
Can this mess be solved by an tool, which would suggest certain automatic order of dependent JARs?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
Google for JarAnalyzer,这至少有助于弄清楚依赖关系是如何建立的。使用 jars,您的 eclipse 项目也在生成。然而你不能真正自动化这一点。想象一下您的 Eclipse 项目之一需要 bad-1.0.jar,而另一个项目则使用 bad-1.2.jar。很多时候,您无法将 1.0 替换为 1.2,因为您的项目将无法再编译。因此,从长远来看,您必须删除过时的 jar,在所有子项目中切换到“通用版本”并修复编译器错误。当你这样做的时候,切换到ivy或maven。
您的 jar 文件是否有正确的名称,或者您是否有 3 个不同版本的 bad.jar,它们在文件系统中看起来相同,但实际上版本不同?如果是这样,首先重命名所有相关的 jar 文件以包含版本号(通常可以在清单文件中找到)...哎呀我曾经做了你所做的事情并用 JArAnalyzer 写给我,有点 groovy 和一些 shell 脚本为项目生成所有 ivy 文件的工具。
Google for JarAnalyzer, that helps at least to figure how the dependecies are build up. Use the jars, your eclipse project is producing, as well. However you can not really automate this. Imagine one of your eclipse projects in needing bad-1.0.jar and another one uses bad-1.2.jar. Very often you can not replace the 1.0 one with the 1.2 one because your project wont compile any more. So in the long run you have to REMOVE outdated jars, switch to a "common version" amoung all subprojects and fix the compiler errors. And while you do that, switch to ivy or maven.
Do your jar files even have proper names or do you have 3 different versions of bad.jar which look the same in the filesystem but are in fact of different version? If so, start by renaming all relevant jar files to include the version number (can often eb found in the manifest file) ... heck I once did what you do and wrote me with JArAnalyzer, a bit groovy and some shell scripts a small tool that generated all the ivy files for the project.
你可以使用maven、ivy来清理混乱:)。那个 spring 无法正常工作,请尝试以下操作:首先清理,然后构建项目。
you can use maven, ivy to clean the mess :) . And that spring doesn't work properly try this:first clean then build the project.
这并不奇怪。正如您所写,类存在于不同的版本中,这并不一定意味着编译错误,而是意味着不同的行为和不同的子依赖项。
避免使用“随机”或“自动顺序”方法。我会建议您使用 Maven 来处理您的依赖项(以便准确地了解哪个库依赖于哪个库)您可能会发现您所包含的许多库不是必需的,并且依赖项管理工具将处理这些库。您“自动”依赖项之间的所有依赖项,但是您必须添加/强制排除特定的库版本。
更重要的是,它将帮助您简化代码并最终删除一行代码和 40 个依赖项...(依赖于滥用的侧框架,例如 Spring 或任何其他框架)。
This is not strange. As you wrote, classes are present in different versions, which does not necessarily means compilation error, but means different behaviour and different sub dependencies.
Avoid a "random" or "automatic order" approach. I would advise you the usage of Maven for handling your dependencies (in order to know precisely which library depends on which one). You will probably discover that many of the libraries you're including are not required, and that the dependency management tool will handle for you "automatically" all dependencies between dependencies, you will have however to add/force exclusion for specific libraries versions.
Much more, it will help you to simplify the code and eventually remove one line of code and 40 dependencies...(relying on a side framework misused such Spring or any other one).