Как упаковать и использовать существующую библиотеку Java с OSGI

Question

После обращения за помощью по управлению зависимостями в разных версиях одних и тех же библиотек на Java было предложено взглянуть на реализации OSGI. Находясь под давлением крайних сроков, я мог бы действительно использовать некоторую помощь, которая спасла бы меня от копания в бесконечных документах OSGI. У меня есть рабочее приложение, которое собирается использовать новый фреймворк. Фреймворк использует разные версии jar-файлов, которые я уже использую, поэтому я хочу упаковать новый фреймворк как пакет OSGI. Могу ли я оставить свое приложение как есть и использовать пакет OSGI только в качестве контейнера в JVM? Это означало бы, что я буду использовать OSGI bundle только для изоляции набора классов от остальной части JVM, чтобы избежать конфликтов между различными версиями классов. другими словами, я хочу использовать OSGI, не перенося весь мой код в настройку на основе OSGI.

С уважением Seref

Answer 1

У меня нет полного ответа для вас здесь, я просто хотел опровергнуть то, что сказал детерб:

Во-первых, у вас должно быть все приложение в рамках OSGi.

Это не правда. Другим подходом было бы встроить контейнер OSGi в хост-приложение.

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

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

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

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

Находясь под крайним сроком давления

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

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

Answer 2

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

Путь с наименьшим количеством проблем, которые я вижу, состоит в том, чтобы взять фреймворк и "обернуть" его и все его зависимости в один пакет. Сделайте пакеты для зависимостей приватными. Для вашего основного проекта сделайте то же самое.

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

В зависимости от настроек вашей сборки, я бы начал с рассмотрения maven-bundle-plugin и / или Bnd . Плагин maven-dependency делает это довольно легко, так как все, что вам нужно сделать, это сказать ему, какие идентификаторы артефактов для встраивания, и он это сделает. Вам необходимо убедиться, что вы указали все встроенные jar-пакеты как частные пакеты.

Это должно работать, если среда не выполняет загрузку классов / AOP, что значительно усложнит OSGify.

Наконец, если вы заинтересованы в быстром non-osgi решении, создайте фреймворк с помощью maven-shade-plugin и просто переименуйте все пакеты для конфликтующих библиотек. , Это, вероятно, будет самым простым, поскольку вы просто перепакуете фреймворк с затененными библиотеками один раз, а затем будете использовать это как свою зависимость.