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

Question

Я хочу использовать проприетарные, не OSGi банки в среде OSGi.Для разработки мы просто перепаковываем / экспортируем его с помощью подключаемого модуля Maven [1].Проблема в том, что по юридическим причинам мы не сможем распространять эти пакеты нашему клиенту, что убивает как встраивание, так и повторную упаковку, которые (AFAIK) являются единственными вариантами (см. [2]).

Перед использованиемOSGi, у нас был раздел в нашем руководстве, описывающий, как поместить эти файлы в папку библиотеки после их приобретения самостоятельно.Учитывая правила OSGi для разрешения классов, это, очевидно, больше не будет работать.

Правильно ли я предположить, что единственный способ решить это - законный, то есть получение лицензии на перераспределение от поставщика пакетов (которыйможет быть изнурительным кошмаром и мешать своевременной доставке) или мне не хватает технического решения?

[1] Как я могу совместно использовать не-OSGi библиотеки между пакетами в контейнере OSGi?

[2] Использование библиотеки не-osgi в приложении osgi

Answer 1

Я видел это требование и в коммерческом проекте. Мы закончили тем, что добавили специальный пакет, который при запуске загрузил необходимые jar-файлы с соответствующих сайтов и добавил их в наши реэкспортные пакеты.

Так

• у нас есть сторонний не OSGi jar J.jar, который мы хотим использовать
• мы добавляем (почти) пустой пакет OSGi с двумя файлами
  • a META-INF/MANIFEST.MF, который реэкспортирует все соответствующие пакеты J.jar
  • простой текстовый файл - META-INF/DOWNLOADS - который указывает, откуда мы можем загрузить J.jar
• у нас есть простой универсальный пакет OSGi (с ранним уровнем запуска), который проходит через все установленные пакеты и проверяет, существует ли META-INF/DOWNLOADS. Если это так, он загружает указанные банки, если их еще нет.

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

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

Answer 2

Я бы просто добавил этот JAR-файл в основной путь к классам Java-приложений, используя его существующее местоположение в папке библиотеки, как вы уже установили.Затем вы можете экспортировать нужные вам пакеты в OSGi, используя свойство org.osgi.framework.system.packages.extra.

Answer 3

Это довольно философски.Что именно представляет собой распространение цифрового контента?

(1) Мы все согласны с тем, что если данный файл jar включен в загрузку вашей установки, то это перераспределение.

(2) Что, если программа установки представляет собой тонкую оболочку, при запуске она загружает больше материалов из Интернета.Если он загружает файл jar с вашего сервера, я думаю, что большинство людей согласятся с тем, что это по сути то же самое, что и (1), и это перераспределение.

(3) Что, если установочная оболочка загружает файл jar изсервер владельца?Предположим, что это автоматизировано без ведома конечного пользователя.

Может ли кто-нибудь действительно утверждать, что (3) очень отличается от (2), и это не перераспределение?

Я думаю, что - это , для всех намерений и целей.Мы эффективно распределяем банку с нашей программой, и то, как это делается под капотом, не имеет отношения к духу лицензии на распространение.Тот, кто получает программу, получает банку вместе с ней, это факт.

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

Answer 4

Возможно, OSGi Remote Services (распределенная OSGi) может быть ответом.Вы бы разместили среду OSGi, которая предоставляет проприетарную библиотеку, и установили остальное на клиентском компьютере.