Что стандартный путь состоит в том, чтобы связать зависимые библиотеки OSGi?
У меня есть проект что ссылки много библиотек с открытым исходным кодом, некоторые новые, некоторые не такие уж новые. Тем не менее они - вся конюшня, и я хочу придерживаться своих выбранных версий, пока у меня нет времени для миграции на более новые версии (я вчера протестировал hsqldb 2.0, и это содержит много изменений API).
Одной из библиотек, которые у меня есть желание встроить, является Jasper Reports, но поскольку Вы все, конечно, знаете, это идет с горой поддержки файлов банки, и я имею, только нуждаются в подмножестве горы (известной) поэтому, я планирую на пользовательский пакет все свои подчиненные библиотеки.
Так:
Все пользовательские - делают их собственные пакеты OSGi для библиотек с открытым исходным кодом, которыми они пользуются или есть ли основной источник версий OSGi общих библиотек?
Кроме того, я думал, что будет намного более просто для каждого из моих пакетов просто встроить их зависимые банки в самом пакете. Действительно ли это возможно? Если я принимаю решение встроить третью сторону foc библиотеки в пакете, я предполагаю, что должен буду произвести 2 файла банки, один без встроенных библиотек (чтобы библиотеки были загружены через путь к классу с помощью стандарта classloader), и одна osgi версия, которая включает встроенный libraryy, поэтому я должен выбрать имя пакета как этот <<myprojectname>> - <<подпроект>>-osgi-.1.0.0.jar?
Если я не могу встроить библиотеки с открытым исходным кодом и выбрать к пользовательскому пакету библиотеки с открытым исходным кодом (через bnd), я должен выбрать уникальное имя пакета для предотвращения конфликта с возможным официальным пакетом? например, <<myprojectname>> - <<3rdpartylibname>> - <<3rdpartylibversion>> .jar?
Мой non-OSGi включил проект, в настоящее время сканирует для пользовательских плагинов через сканирование папок META-INF в моих различных сменных банках через Service.providers (...). Если я пойду OSGi, то этот механизм будет все еще работать?
5 ответов
Я предпочитаю не встраивать зависимые jar-файлы (да, это возможно). Это вызывает две проблемы:
1) Повторное использование этого кода невозможно. Многие пакеты могут просто делать одно и то же (встраивать одну и ту же банку), и в результате вы получаете одну и ту же банку, установленную много раз. Вы можете утверждать, что ваш пакет также может экспортировать интерфейсы для встроенного jar-файла, но это становится некрасивым, поскольку вы не должны нести ответственность за раскрытие этого кода. Это также упрощает доступ к нескольким версиям библиотеки или нескольким поставщикам одной и той же версии.
2) Это специфично для Eclipse - встроенные jar-файлы не разрешаются должным образом в среде разработки (все еще работают во время выполнения). Мой пакет может зависеть от пакета на моей целевой платформе, и он не сможет разрешить элементы во встроенных jar-файлах, для работы их необходимо импортировать в рабочую область.
Я обнаружил, что большинство jar-файлов с открытым исходным кодом уже были любезно собраны хорошими ребятами из Spring . Доступны и другие репозитории, но, к сожалению, я потерял ссылки на них.
Проект Eclipse Orbit также создал пакеты из многих часто используемых сторонних банок.
Возможно, вы ищете что-то вроде Maven ? Хотя не уверен, как это будет работать с OSGi. Вы можете найти небольшую информацию о Jasper Reports с Maven здесь: http://mvnrepository.com/artifact/jasperreports/jasperreports
Чтобы конкретизировать вопросы, которые вы задали.
Не каждый делает свое. См. В моем предыдущем ответе ссылку на упаковку Eclipse сторонних библиотек в виде пакетов. Если вы не можете найти уже упакованную версию, вам придется создать свою собственную.
Лучше заключить двоичные зависимости в отдельный пакет, чем включать jar как двоичный файл в пакет кода. Выберите любое имя пакета, которое вам нужно, важен его импорт и экспорт. Использование пространства имен для имени пакета с именем вашего проекта гарантирует, что вы не столкнетесь с коллизиями.
Получение доступа к области хранения пакетов для сканирования не является невозможным, но для этого обычно требуется информация, специфичная для среды выполнения OSGi, о том, как и где извлекаются пакеты. Так что это возможно, но непросто.
Spring создал пакеты osgi для большинства библиотек с открытым исходным кодом, и я вижу там отчеты о jasper. проверьте их репозиторий пакетов @ http://www.springsource.com/repository/app/bundle