Управление большим приложением OSGi

Question

У меня есть большое, растущее приложение OSGi с несколькими пакетами.Мне любопытно узнать, как лучше всего управлять приложениями такого типа.В настоящее время я использую Eclipse и Maven, но, хотя они отлично подходят для создания пакетов (через maven-bundle-plugin), на данный момент управлять всем приложением непросто.

Я хотел бы иметь либо ОДНУ конфигурацию запуска, либо ОДИН pom.xml, который можно запустить, и все приложение/проект будет построено и запущено.Кроме того, мне хотелось бы иметь что-то, что было бы полезно для отладки.

Я слышал о PAX Construct и установил его в Eclipse, но пока это мало помогло (возможно, я использую его неправильно).

Я уверен, что есть люди с большими приложениями OSGi, которыми правильно управляют.Любой совет, которым можно было бы поделиться, очень помог бы.

Спасибо, Стивен

Answer 1

Настройка конфигурации возможна через Pax Runner . Он позволяет выбрать реализацию платформы OSGi, указать профили (предварительно упакованные наборы пакетов для некоторой роли, например, web , log , ds и т. Д. .) и имеет хорошую поддержку инициализации, например, он может загружать пакеты из репозитория Maven. В результате вы можете иметь конфигурацию запуска, например

--platform=felix
--log=INFO
--profiles=scalamodules,ds,config,log
mvn:com.my/bundle/1.0.1-SNAPSHOT@update
# other bundles

Если ваше приложение очень велико или у вас есть другие приложения, есть способ также создать собственные профили.

Answer 2

Хорошо...

Все зависит от того, что вы подразумеваете под «управлением» приложением.

Для запуска, сборки и отладки во время разработки Eclipse IDE должен идеально подойти.

Мейвен...Ничего не могу сказать, так как сам никогда им не пользовался.

У нас есть довольно большое приложение на основе Eclipse (на самом деле несколько), и со стороны разработчиков мы не используем ничего особенного, кроме Eclipse и встроенного в него SCM.

На сервере сборки cc мы также используем headless eclipse для сборки и упаковки.

В последнее время настройка рабочей области со всеми зависимостями и промежуточными этапами сборки немного вышла из-под контроля, поэтому мы занимаемся расследованием. Бакминстер для управления материализацией ресурсов целевой платформы и рабочей области.

Если это сработает, мы, вероятно, тоже перейдем к строительству вместе с Баки — это выглядит многообещающе.

(У меня нет опыта работы с PAX, но на первый взгляд он тоже выглядит многообещающе...)

Answer 3

Я довольно новичок в OSGi, но,

было бы невозможно использовать OBR-сервис таким образом, чтобы у вас будет один файл репозитория OBR, который требует комплектов и позволить сервису OBR выяснить зависимости и заполнить ваш OSGIhost для вас?

Answer 4

Эта область, на мой взгляд, сейчас очень слаба. OSGI на самом деле ничего не определяет в развертывании или упаковке, так что это зависит от других сред (например, Eclipse), чтобы придумать свой собственный способ сделать это.

Если вы создаете приложение RCP (базовое Eclipse), то системы eclipse делают все это, вплоть до создания exe-файлов и т. д. Однако сборки в основном выполняются в рабочей области Eclipse, безголовые сборки сложнее. Проект Tycho пытается сделать это более разумным путем объединения циклов сборки Maven и Eclipse, однако он по-прежнему сосредоточен на приложениях RCP, а не на общих OSGI.

Если вы не выполняете RCP, что также является моей ситуацией, вам, вероятно, придется применить собственное решение, так как я не нашел никакого общего решения. Вот схема того, что мы делаем:

Мы определяем один проект POM, в котором перечислены все пакеты, содержащиеся в вашем приложении. Все, что делает этот проект, это перечисляет ссылки - давайте назовем его проектом «bundle-list».

Затем мы используем pax provision для запуска проекта в режиме разработки. Это достигается созданием pom «bundle-list» как родительского pom-пакета pax-проекта (обычно в папке «provision»). Затем, когда вы запускаете pax, он использует список пакетов из этого проекта для запуска OSGI. Ссылки на комплект в проекте «комплект-список» должны быть помечены как «предоставленные» для того, чтобы это работало.

Затем для создания дистрибутива у нас есть еще один проект. Этот проект также имеет проект 'bundle-list' в качестве родителя. Этот проект использует различные плагины для создания дистрибутива, в том числе загрузку jar-пакетов. В дистрибутив входят скрипты, запускающие OSGI, но они написаны от руки, здесь нет систем pax.

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