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

Question

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

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

Итак:

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

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

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

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

Answer 1

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

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

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

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

Answer 2

Проект Eclipse Orbit также сделал пакеты из множества обычно используемых сторонних банок.

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

Answer 3

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

Answer 4

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

Answer 5

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

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

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

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

Answer 6

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