Выявление всех конфликтующих пакетов / классов ссылочных jar-файлов в проекте Eclipse.

Question

В настоящее время я имею дело с огромным проектом Eclipse (не написанным мной).Этот проект не использует никаких инструментов управления зависимостями.Он ссылается на сотни JAR-файлов.

Некоторые из этих JAR-файлов содержат одинаковые пакеты (и классы), но в разных версиях.В настоящее время разрешение конфликтов работает вручную (и случайным образом!), Переупорядочивая эти JAR-файлы в Order&Export (в свойствах проекта).

Это было сделано в течение длительного времени, и теперь существует множество пакетов / классовразные поставщики / версии / линейки продуктов.

Изменение порядка приводит к сбою некоторых частей проекта, в то время как другие части начинают работать, и наоборот.Как ни странно, многие заказы не вызывают ошибки сборки, а только ошибки времени выполнения.

Можно ли решить эту проблему с помощью инструмента, который предлагает определенный автоматический порядок зависимых JAR-файлов?

Answer 1

Google для JarAnalyzer, который помогает по крайней мере понять, как строятся зависимости. Используйте фляги, ваш проект затмения также производит. Однако вы не можете автоматизировать это. Представьте, что один из ваших проектов затмения нуждается в bad-1.0.jar, а другой использует bad-1.2.jar. Очень часто вы не можете заменить 1.0 на 1.2, потому что ваш проект больше не будет компилироваться. Таким образом, в конечном итоге вы должны УДАЛИТЬ устаревшие файлы jar, переключиться на «общую версию» среди всех подпроектов и исправить ошибки компилятора. И пока вы это делаете, переключитесь на плющ или мавен.

У ваших файлов jar даже есть собственные имена, или у вас есть 3 разные версии bad.jar, которые одинаково выглядят в файловой системе, но на самом деле имеют другую версию? Если это так, начните с переименования всех соответствующих файлов JAR, чтобы включить номер версии (часто это можно найти в файле манифеста) ... черт, я однажды сделал то, что вы делаете, и написал мне с JArAnalyzer, немного Groovy и некоторые небольшие скрипты инструмент, который сгенерировал все файлы плюща для проекта.

Answer 2

"Как ни странно, много заказов не вызывают ошибок сборки, а только во время выполнения ошибки ".

Это не странно. Как вы писали, классы присутствуют в разных версиях, что не обязательно означает ошибку компиляции, но означает различное поведение и разные подчиненные зависимости.

Избегайте «случайного» или «автоматического заказа». Я бы посоветовал вам использовать Maven для обработки ваших зависимостей (чтобы точно знать, какая библиотека зависит от какой). Вы, вероятно, обнаружите, что многие из включаемых вами библиотек не требуются, и что инструмент управления зависимостями будет обрабатывать для вас «автоматически» все зависимости между зависимостями, однако вам придется добавить / принудительно исключить для определенных версий библиотек.

Гораздо больше, это поможет вам упростить код и в конечном итоге удалить одну строку кода и 40 зависимостей ... (полагаясь на стороннюю платформу, неправильно использовавшую такую ​​Spring или любую другую).

Answer 3

вы можете использовать maven, плющ, чтобы убрать беспорядок :). И эта пружина не работает должным образом, попробуйте это: сначала очистите, а затем соберите проект.