OSGI - обработка сторонних JAR-файлов, необходимых для пакета

Question

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

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

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

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

Answer 1

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

Bundle-ClassPath: .,my3rdparty.jar

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

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

Answer 2

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

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

Answer 3

В пакет можно встраивать не-OSGi-зависимости.

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

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

Answer 4

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

Answer 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>

Answer 6

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