Каков стандартный способ объединения библиотек, зависящих от OSGi?

У меня есть проект, который ссылается на ряд библиотек с открытым исходным кодом, некоторые новые, некоторые не такие новые. Тем не менее, все они стабильны, и я хочу придерживаться выбранных мной версий, пока у меня не будет времени перейти на более новые версии (вчера я протестировал hsqldb 2.0, и он содержит много изменений API).

Одна из библиотек, которую я хочу внедрить, — это Jasper Reports, но, как вы все наверняка знаете, она поставляется с горой поддерживающих jar-файлов, и мне нужно только подмножество горы (известной), поэтому я планирую собрать все на заказ. моих зависимых библиотек.

So:

  • Все ли делают свои собственные пакеты OSGi для библиотек с открытым исходным кодом, которые они используют, или существует главный источник OSGi-версий общих библиотек?

  • Кроме того, я подумал, что для каждого из моих пакетов было бы намного проще просто встроить свои зависимые банки в сам пакет. Это возможно? Если я решу встроить сторонние foc-библиотеки в пакет, я предполагаю, что мне нужно будет создать 2 файла jar, один без встроенных библиотек (для загрузки библиотек через путь к классам через стандартный загрузчик классов) и одну версию osgi, которая включает встроенная библиотека, поэтому я должен выбрать имя пакета, подобное этому ‹‹myprojectname››-‹‹subproject››-osgi-.1.0.0.jar ?

  • Если я не могу внедрить библиотеки с открытым исходным кодом и выберу пользовательский пакет библиотек с открытым исходным кодом (через bnd), должен ли я выбрать уникальное имя пакета, чтобы избежать конфликта с возможным официальным пакетом? например ‹‹myprojectname››-‹‹3rdpartylibname››-‹‹3rdpartylibversion››.jar ?

  • Мой проект, не поддерживающий OSGi, в настоящее время сканирует пользовательские плагины, сканируя папки META-INF в моих различных банках плагинов через Service.providers(...). Если я перейду на OSGi, этот механизм все еще будет работать?


java plugins packaging osgi
person Chris    schedule 10.06.2010    source источник

Ответы (6)


arrow_upward
8
arrow_downward

Я предпочитаю не вставлять зависимые банки (да, это возможно). Это вызывает две проблемы,

1) Повторное использование этого кода невозможно. Многие пакеты могут просто делать одно и то же (вставлять одну и ту же банку), и в итоге вы получите одну и ту же банку, установленную много раз. Вы можете утверждать, что ваш пакет также может экспортировать интерфейсы для встроенного jar-файла, но это становится уродливым, поскольку вы не должны нести ответственность за раскрытие этого кода. Это также упрощает доступ к нескольким версиям библиотеки или к нескольким поставщикам одной и той же версии.

2) Это специфично для Eclipse. Встроенные файлы jar не разрешаются должным образом в среде разработки (все еще работают во время выполнения). Мой пакет может зависеть от пакета на моей целевой платформе, и он не сможет разрешить элементы во встроенных банках, для работы их необходимо импортировать в рабочую область.

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

person Robin    schedule 10.06.2010
comment
На банках Spring напечатан Spring, плюс они кажутся более старыми версиями библиотек (например, версия 2.0.5 Jasper Reports). Теоретически OSGi кажется хорошим, но кажется, что каждый создает свои собственные пакеты (включая Spring), что как бы противоречит цели. Не говоря уже о проблеме JDBC с OSGi. Ад DLL был решен с помощью пути к классам. Ад класса был решен с помощью OSGi. Что спасет нас от ада пакетов OSGi? - person Chris; 14.06.2010
comment
@Chris - верно в отношении названия, но, поскольку нет никакого центрального органа для предоставления пакетов, и они не создаются владельцем, это кажется разумным компромиссом. По крайней мере, вы знаете, откуда он взялся, и после развертывания это не имеет значения. Что касается его полезности, это просто еще один инструмент на поясе, весьма полезный для создания систем подключаемого типа. - person Robin; 14.06.2010
comment
Идея использования весеннего репо в качестве источника для внешних плагинов rcp великолепна, но где я могу найти URL-адрес сайта репо/обновления, который мне нужно добавить в мое целевое определение. Я пытался найти его в Google, но не смог найти рабочий URL. Я знаю, что добавление URL-адреса к ответу скоро устареет. Но это определенно поможет, и, возможно, другие обновят его в будущем... - person Jens; 17.01.2014

arrow_upward
2
arrow_downward

Возможно, вы ищете что-то вроде Maven? Не уверен, как это будет работать с OSGi. Вы можете найти небольшую информацию о Jasper Reports с Maven здесь: http://mvnrepository.com/artifact/jasperreports/jasperreports

person Patrick Hendricks    schedule 10.06.2010
comment
Ссылка не для пакетов OSGi. Но это хорошая ссылка, чтобы увидеть зависимости Джаспера. - person Chris; 14.06.2010

arrow_upward
2
arrow_downward

В рамках проекта Eclipse Orbit также были созданы пакеты из многих часто используемых сторонних jar-файлов.

http://www.eclipse.org/orbit/

person James Branigan    schedule 10.06.2010
comment
Спасибо за ссылку. К сожалению, мой вопрос остается. - person Chris; 14.06.2010

arrow_upward
1
arrow_downward

Чтобы конкретизировать вопросы, которые вы задали.

Каждый не делает свое. См. мой предыдущий ответ для ссылки на упаковку Eclipse сторонних библиотек в виде пакетов. Если вы не можете найти и уже запакованную версию, вам придется сделать свою собственную.

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

Получение доступа к области хранения пакетов для сканирования не является невозможным, но, как правило, требуется конкретная информация среды выполнения OSGi о том, как и где извлекаются пакеты. Так что это возможно, но не просто.

person James Branigan    schedule 14.06.2010
comment
Как через OSGi узнать, какие плагины доступны через неустановленные пакеты? Обычно я сканирую путь к классам в поисках файла, который я сейчас помещаю в META-INF. Кажется, что OSGi несовместим со всем, что в настоящее время использует путь к классам для модульности. Мой проект, не поддерживающий OSGi, в настоящее время сканирует пользовательские плагины, сканируя папки META-INF в моих различных банках плагинов через Service.providers(...). Если я перейду на OSGi, этот механизм все еще будет работать? - person Chris; 20.06.2010

arrow_upward
1
arrow_downward

Spring создал пакеты osgi для большинства библиотек с открытым исходным кодом, и я вижу там отчеты jasper. проверьте их репозиторий пакетов @ http://www.springsource.com/repository/app/bundle< /а>

person Aravind Yarram    schedule 24.06.2010

arrow_upward
0
arrow_downward

мы использовали Maven с OSGI, мы объявляем зависимости пакета в его pom.xml, а вы не больше не нужно о них беспокоиться.

person cues7a    schedule 02.08.2010
comment
Однако это не совсем так. Вам нужно получить или создать пакеты самостоятельно (не все в комплекте), вам нужно разрешить развертывание пакетов и управлять правильным управлением версиями (вы не можете просто заменить пакет на более позднюю версию — зависимым пакетам может потребоваться более старая версия ) и так далее. Это особенно важно, если развертыванием занимается другое подразделение компании, например, системные администраторы. - person extraneon; 13.10.2010