Как скрыть встроенные зависимости при использовании пакета OSGI с maven?

Question

Есть ли способ использовать пакет OSGI в качестве зависимости maven, не помещая все пакеты из него в путь к классам, который он даже не экспортирует?

Справочная информация о вопросе: Мы только что добавили *Пакет 1003 * org.apache.sling.xss является зависимостью maven в нашем проекте.Как вы можете видеть в pom.xml , он просто экспортирует пакет org.apache.sling.xss, но встраивает различные зависимости прямо в jar как Private-Package .В то время как OSGI скрывает это от других пакетов, Maven - нет.Таким образом, мы получаем коллизии: org.apache.sling.xss встраивает, например, версию 1.7.0 commons-beanutils, которая несовместима с более новой версией commons-beanutils, которую мы использовали, так что теперь мы получаем ошибки компиляции.

Есть ли какое-то хорошее решение для этого - как с нашей точки зрения, так и с точки зрения сопровождающих пакета org.apache.sling.xss?В идеале вы должны получить только экспортированный пакет org.apache.sling.xss в classpath, если будете использовать этот пакет.Поэтому, возможно, хорошим решением было бы, если бы org.apache.sling.xss предоставил отдельный jar API, содержащий только этот класс?Есть ли стандартный способ сделать это или другое решение?Можем ли мы как-то сказать maven просто включить этот пакет в classpath?(Я знаю, что у maven есть исключение зависимостей , но здесь это не поможет, поскольку проблемным является не транзитивная зависимость sling.xss, а фактически включенная в jar org.apache.sling.xss.)

Answer 1

К сожалению, нет хорошего способа обработки таких пакетов с помощью Maven.

Рекомендованным способом является разделение пакета на пакет API, который просто определяет API, и пакет реализации, который импортирует API и импортирует или встраивает все зависимости реализации.

Таким образом, потребители будут зависеть от API только от maven, и проблема вообще не возникает.

Можете ли вы открыть проблему jira для sling xss для предоставления пакета API?

Answer 2

Вы можете включить в свою систему сборки шаг, который выполняет разрешение OSGi, например, используя bnd-export-maven-plugin .

Таким образом, сборка в целом завершится неудачей, если вы напишите код, который зависит от неэкспортированного пакета другого пакета. Это связано с тем, что bnd автоматически добавит Import-Package для пакета, который вы использовали в вашем пакете, но на этапе разрешения не удастся найти соответствующий Export-Package в другом пакете.

Конечно, это не идеально. Вы по-прежнему сможете написать код в своей IDE и скомпилировать его с maven-compiler-plugin. Но вы по крайней мере узнаете о проблеме до того, как попадете во время выполнения.