Почему репозитории в модели рабочей области bnd не поддерживают транзитивные зависимости?

В OSGi создание пакета и сборка приложения — две совершенно разные вещи. При создании пакетов с помощью maven вы, конечно, используете транзитивные зависимости. Результатом работы плагина maven-bundle-plugin или bnd-maven-plugin являются записи в манифесте jar. Они определяют такие вещи, как импортированные или экспортированные пакеты. Этот результат не содержит транзитивных зависимостей. Эти пакеты можно использовать как в модели рабочей области, так и в модели maven.

Сборка приложения — это другой процесс. Там вы строите репозиторий, который представляет собой список возможных пакетов для установки. В модели рабочей области вы перечисляете каждый пакет без транзитивных зависимостей. В сборке приложения на основе maven вы определяете репозиторий, используя зависимости pom. Там используются транзитивные зависимости.

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

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

Основная причина в том, что OSGi — это спецификация для системы компонентов многократного использования. Если вы попытаетесь сделать это с транзитивными зависимостями, вы обнаружите, что столкнетесь с проблемами во время сборки:

• конфликты версий — компонент A использует версию 1 X, компонент B использует версию 2 X. Эти конфликты часто сужаются в транзитивных системах, таких как Maven, но бомбы замедленного действия скрываются, чтобы взорваться.
• зависимости от среды — некоторые компоненты зависят от Windows, другие — от Linux. Очень трудно примирить эти различия.
• совместимость версий. Часто компоненты могут работать вместе, но их транзитивные зависимости делают это невозможным.

Чтобы решить эту проблему, OSGi изобрела сервисную модель. Сервисная модель позволяет компоненту зависеть от API. Когда вы зависите от API, у вас больше нет транзитивных зависимостей, поскольку транзитивные зависимости почти полностью связаны с зависимостями реализации. Конечно, существует зависимость от API, но она стала более размытой, поскольку от этого зависят как потребитель API, так и поставщик API. Это в корне меняет модель зависимости в лучшую сторону, но мало кто это понимает.

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

Конечно, это лишает некоторых удобств на ранних стадиях разработки. Там, где в транзитивной модели, такой как Maven, все должно компилироваться из коробки, в bnd вам нужно заранее подумать о своих зависимостях и зависимостях вашего компонента. Это неудобно и раздражает пользователей Maven, но необходимо сделать компоненты повторно используемыми в очень разных средах. Maven имеет тенденцию блокировать среду выполнения в часто несовместимых конфигурациях, в OSGi вы не хотите, чтобы среда выполнения имела какие-либо ненужные ограничения для максимального повторного использования ваших компонентов.

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

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