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

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

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

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

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

Ответ 1

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

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

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

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

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

Ответ 2

Есть выбор:

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

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

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

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

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