OSGI - обработка сторонних JAR, требуемых пакетом

Я только начинаю разработку OSGI и изо всех сил пытаюсь понять, как лучше обращаться с зависимыми JAR.

то есть. если я создаю пакет, вероятность того, что мне нужно будет использовать несколько сторонних JAR. Когда я создаю JAR для пакетного развертывания для развертывания в OSGI, очевидно, что эти сторонние JAR не включены и, следовательно, пакет не будет запущен.

Я понимаю, что один из вариантов заключается в том, чтобы превратить эти JAR в пакеты, а также развернуть их в контейнер OSGI. Однако, если их нужно использовать только одним пучком, это не кажется идеальным.

Какое лучшее решение для этого? Могут ли JAR быть встроены в JAR пакета и если это разумный подход?

Ответ 1

Я бы почти всегда собирал каждую банку отдельно. Сам OSGi предназначен для модуляции, и вы принимаете всю систему ad absurdum, не делая этого.

Если вы хотите конвертировать JAR в пакеты, вы можете использовать BND Tool, написанный Peter Kriens. Но сначала я предлагаю вам найти пакет в SpringSource Enterprise Bundle Repository, если они еще не сделали эту работу для вас.

Ответ 2

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

Bundle-ClassPath: .,my3rdparty.jar

Если вы хотите разместить стороннюю банку в подкаталоге, укажите путь без использования заголовка ./, например

Bundle-ClassPath: .,lib/my3rdparty.jar # (not ./lib/my3rdparty.jar)

Ответ 3

Можно встраивать не связанные с OSGi зависимости в пакет.

Легкий способ сделать это - использовать Maven для управления вашими зависимостями и Maven Bundle Plugin для создания вашего пакета. Ознакомьтесь с инструкциями <Embed-Dependency> и <Embed-Transitive> плагина Maven Bundle, описанного в разделе Вложения зависимостей на странице документации подключаемого модуля.

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

Ответ 4

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

Ответ 5

Вот пример, если вы используете Maven Bundle Plugin.

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

    <Import-Package>
        <!-- this was imported by one of the dependencies; I don't really need it -->
        !org.apache.jackrabbit.test,
        *
    </Import-Package>
    <Include-Resource>
        lib/concurrent-1.3.4.jar,
        lib/jackrabbit-core-2.6.5.jar,
        lib/jackrabbit-spi-2.6.5.jar,
        lib/jackrabbit-spi-commons-2.6.5.jar,
        lib/lucene-core-3.6.0.jar,
        lib/tika-core-1.3.jar
    </Include-Resource>
    <Bundle-ClassPath>
        .,
        concurrent-1.3.4.jar,
        jackrabbit-core-2.6.5.jar,
        jackrabbit-spi-2.6.5.jar,
        jackrabbit-spi-commons-2.6.5.jar,
        lucene-core-3.6.0.jar,
        tika-core-1.3.jar
    </Bundle-ClassPath>

Ответ 6

Можно ли использовать OSGI для переопределения загружаемых во время выполнения загрузочных загрузочных машин bootstrap, например, если мы хотим переопределить JAXP1.4.5, доступный с Java7, для JAXP1.6, есть функция -Dendorese для переопределения API по умолчанию для обновленного API. Можем ли мы сделать это с помощью OSGI.