Как вы обрабатываете несколько версий jar с большим количеством FOSS/COTS?

Question

У нас есть продукт Java, который использует много программного обеспечения FOSS/COTS. Ряд наших «внешних» используют один и тот же продукт, но другую версию. Например, Ant 1.6.5 и Ant 1.7.0; или несколько версий xerces. Что меня беспокоит, так это то, что поведение нашего приложения может измениться или ухудшиться, эпический сбой, если мы изменим порядок, в котором сгруппирован класс. Мы используем скрипты vbs для установки переменных среды для каждого пути класса продукта, а затем файлы Ant xml, которые ссылаются на эти переменные среды.

Итак, несколько вопросов:

1. Как я могу управлять несколькими версиями одного и того же банку при использовании так много различных внешних компонентов? Конечно, я не могу просто найти все уникальные банки и поставить их на один большой путь - или я могу?
2. Есть ли более умный способ связать наши зависимости сборки (и classpath) вместе?

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

Примечание: не стреляйте в посланника. Эта система была введена в действие несколько лет назад, задолго до того, как я попал сюда. Я просто уборщик.

Answer 1

Maven. Занимает некоторое время, чтобы понять это и настроить его, но он очень волшебный, когда он работает.

См http://maven.apache.org/download.html

Answer 2

Вы можете добавить Ivy в свой муравей строить явно версии зависимостей. Когда дело доходит до создания classpath, я предлагаю вам стремиться к ситуации, когда у вас нет нескольких версий одной и той же библиотеки. У нас было какое-то очень раздражающее поведение, когда IDE создавала путь класса с использованием транзитивных зависимостей, но мы строим нашу путь к классам unix в алфавитном порядке, в результате чего загружается один из JavaMail/Genronimo-JavaMail Saxon/Xalan в зависимости от того, где вы запускали код.

Как уже упоминалось в другом ответе, если у вас есть время для повторной работы вашей системы сборки, вы должны посмотреть на maven.

Я очень нравится этот talk Джон Смарт на поддержание вашей среды сборки

Answer 3

Если вы должны поставить все банки в том же классе загрузчиком, то вы можете использовать Maven, чтобы определить набор зависимостей. Это позволит выбрать последнюю версию каждой библиотеки, необходимую для набора зависимостей. (Например, Ant 1.7.0 будет выбран, а не 1.6.5.) Эта схема работает хорошо - если библиотека не обратно совместима с более ранней версией. Следовательно, это хорошая идея, чтобы проверить соответствующие функции/функции вашего приложения при изменении зависимостей.

Альтернатива, которая применима только в том случае, если библиотеки можно разделить на интерфейс и реализацию, заключается в загрузке интерфейсов в общий загрузчик классов и в зависимости от реализации в зависимом от пользователя загрузчике классов. Это изолирует каждую зависимость, предоставляя ей собственный загрузчик классов. Это то, что делает OSGi.

Answer 4

Это то, что OSGi было разработано для решения: наличие нескольких независимых версий этих же банок в вашем приложении.

Answer 5

Я не уверен, что предложения по использованию Maven или Ivy решат настоящую проблему. Они могут очищать декларацию зависимостей, но они ничего не будут делать о конфликтах.Если вам нужно отправить две разные версии одной и той же библиотеки (потому что использование последней версии не обязательно будет работать, если библиотека не поддерживает обратную совместимость), вы можете использовать jarjar для переупаковки библиотек с разными именами пакетов, чтобы обе версии могли при необходимости, загружаться.