Как вы справляетесь с несколькими версиями банок с большим количеством 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

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

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

Answer 3

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

Answer 4

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

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

Мне очень нравится разговор Джона Смарта о поддержании вашей среды сборки

Answer 5

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