Вы должны предоставить зависимые библиотеки в клиентском фляге?

Question

Мы предоставляем клиентский jar для других внутренних приложений для подключения к REST API нашего приложения. Наш API зависит от нескольких стандартных библиотек Джакарты. Рекомендуется ли включать эти JAR-файлы в наш клиентский JAR-файл? Или вы просто документируете зависимости, и клиенты сами должны убедиться, что у них есть эти файлы в их пути к классам?

Answer 1

Вы должны , а не связать любые сторонние банки в вашу собственную банку как банку uber, но было бы хорошо включить копию всех банок, которые требуются в вашем дистрибутиве, скажем, в lib каталог или что-нибудь.

Основная причина этого заключается в том, что ваши клиенты могут использовать какую-либо форму системы управления зависимостями (maven / ivy и т. Д.), А предоставление пакетов и классов, которые на самом деле не принадлежат вашему проекту, лишит законной силы эти схемы.

Существует одна альтернатива: использовать плагин maven shade для перемещения ваших зависимостей в пространство имен вашего пакета. Это, конечно, имеет недостаток, заключающийся в том, что вы увеличите размер кода своей библиотеки, но, с другой стороны, вы можете почти гарантировать версии своих зависимостей, не влияя на любые другие библиотеки, которые могут использовать ваши клиенты.

РЕДАКТИРОВАТЬ: в ответ на комментарий Маркуса Леона:

Возможные решения без комплектации / перемещения:

• Документация, убедитесь, что вы документируете свои зависимости и любые известные конфликты с предыдущими версиями - на самом деле никто не читает ее
• Распространяйте свою библиотеку через управляемую систему зависимостей ... как репозиторий maven или ivy, они позволяют вам задавать в очень специфический набор границ (включая верхний), каковы ваши зависимости - все еще могут быть переопределены только вашими клиентами знаю, что они делают это
• Добавление информации OSGi в MANIFEST.MF - полезно, только если ваши клиенты действительно используют OSGi
• Если ваши зависимости были построены с использованием maven или в файлах манифеста есть информация о версии, вы можете написать какую-нибудь процедуру проверки, которая сканирует путь к классам для них и проверяет там версии - немного экстремально

В конце концов, чрезвычайно трудно убедиться, что у вас есть зависимости, которые вы хотите, поскольку java - язык с поздним связыванием, возможно, что ваши зависимости (даже если они связаны) будут переопределены кем-то, включая другую версию, перед вашей на пути к классам ,

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

Answer 2

Вы должны включить любые банки, от которых вы зависите. Если вы разрешаете клиенту предоставлять стандартные файлы jar, вы полагаетесь на них, чтобы предоставить правильную версию. Для вас обоих будет гораздо более безболезненно, если вы включите версии, с которыми, как вы знаете, работает ваше приложение.

Answer 3

Преимущества упаковки в одну банку:

• простота для клиента

Минусы комплектации:

• невозможность обновления версий зависимых библиотек
• скрытие необходимых библиотек может фактически привести к потенциальным конфликтам в клиенте с этими дополнительными библиотеками
• сложность для вас в процессе сборки (но способы сделать это довольно легко в Ant / Maven)
• некоторые библиотеки с манифестами не могут быть просто переписаны и перефразированы - вам нужно объединить информацию манифеста. Хотя есть поддержка Ant и Maven.

Другой вариант - использовать один основной jar (ваш код) с атрибутом манифеста class-path, установленным для всасывания других jar. Лично мне это не нравится, так как эти полускрытые зависимости действительно легко пропустить.

В конце концов, если вы говорите только об одной или двух банках, я бы оставил их разделенными. Если вы говорите 10 или 15, вы можете рассмотреть возможность комплектации.

Answer 4

Вы должны включить эти банки, если развертываете приложение как отдельное приложение. Если вы развертываете исходный код для сборки, и вы предоставляете файл maven pom, то вам это не обязательно.

Answer 5

Вы выражаете беспокойство по поводу очень специфических зависимостей версий библиотеки (и я могу понять, что, учитывая, насколько тесно, скажем, Hibernate находится между различными модулями - только некоторые версии Hibernate-аннотаций работают с одним ядром hibernate, который, в свою очередь, должен использоваться с определенным hibernate-валидатором).

Если вы знаете, что пакет должен работать как часть гораздо более крупной платформы (скажем, как плагин для фреймворка, который может загружать свои собственные jar-файлы), вам действительно нужна более мощная мульти-версия загрузки классов OSGI. (он же JSR-291): Технология OSGI

В среде с поддержкой OSGI, такой как Spring, Eclipse, Jonas или Glassfish, вы можете указать в файле XML свои конкретные зависимости версий, и если вы зависите от пакета libfoo-1.1.4, тогда как другой плагин зависит от libfoo-2.0a, менеджер зависимостей OSGI обеспечит загрузку каждой верной версии.