Лучшая стратегия для работы с необязательными зависимостями

Question

Я сейчас нахожусь в процессе удаления зависимости Spring от Flyway . Однако в будущем могут потребоваться другие типы зависимостей для поддержки подмножества пользователей (например, поддержка JBoss VFS).

Каков лучший способ поддержки необязательных зависимостей (необязательно = true в Maven POM)?

Качества решения будут:

• Простота использования для конечных пользователей (минимальная работа, необходимая для использования функциональности при наличии зависимости)
• Простота использования для разработчиков (код, имеющий дело с необязательной зависимостью, должен быть максимально читабельным и понятным)
• Нет ненужных обязательных зависимостей (если некоторым конечным пользователям эта функциональность не нужна, нет необходимости извлекать зависимость)

Answer 1

Я думаю, что дополнительная функция зависимостей Maven довольно ограничена.

http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html

Необязательные зависимости не будут удалены (как транзитивные зависимости) по умолчанию. Однако, если вашим пользователям необходимо использовать эти дополнительные функции, недостающие зависимости должны быть явно объявлены в их POM.

Лично мне неясно, насколько это полезно для пользователей .... Я предполагаю, что необязательные зависимости в вашем документе POM do документируют, от каких версий зависит ваш код. Однако не все пользователи будут читать POM, все, что они увидят, это ошибка «NoClassDef Found»: - (

Мое последнее замечание состоит в том, что это один из тех редких сценариев, где менеджер зависимостей, такой как ivy , предлагает большую гибкость. У Айви есть понятие, называемое «конфигурации». Авторы модулей могут собирать различные комбинации зависимостей, например, «с пружиной» или «без пружины».

Answer 2

На выбор:

• сохранить проект в одном модуле; и используйте необязательные зависимости.
• разбить проект на несколько модулей; где каждый модуль имеет (не обязательно) зависимость от любых библиотек;

Я думаю, что первое имеет больше смысла в большинстве случаев: пользователям нужно найти способ обходить меньшее количество артефактов. Как правило, им придется добавлять меньше новых зависимостей в их pom. Если код для поддержки сторонних проектов не является большим, это также поможет сократить время загрузки maven (меньше циклов). При последнем подходе вы можете оказаться в неловких ситуациях, когда пользователь определил свой собственный набор версий, но только для некоторых сторонних зависимостей.

Я предпочитаю видеть необязательные зависимости в pom (иногда я смотрю, для какой версии он построен). Это правда, что некоторые люди могут не смотреть. Я думаю, что копируемые и вставляемые фрагменты pom на сайте - лучшее решение для этого. Например, если у вас есть страница об интеграции Spring, вы можете поместить соответствующий фрагмент pom на эту страницу.

Я бы посоветовал хранить несвободные зависимости (или что-либо, что не так легко разрешается) в отдельном модуле maven, чтобы участники всегда могли создать основной артефакт. (У меня была эта проблема с Кварцем, который IIRC имеет необязательную зависимость от JAR-файла Oracle JDBC).

Редактировать: Если вы беспокоитесь о том, что пользователи видят ошибки NoClassDefFoundErrors, не помешает проверить, что класс может быть разрешен перед его использованием. Например, вы можете сделать исключение и выдать более значимое сообщение об ошибке, указывающее пользователю на документацию. SLF4J является хорошим примером этого.