Finding out all conflicting packages/classes of referenced jars in an Eclipse project

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 con开发者_C百科flicts 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?

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.

you can use maven, ivy to clean the mess :) . And that spring doesn't work properly try this:first clean then build the project.

"Strangely, lots of orders do not cause build errors, but only runtime errors."

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).