Как я могу управлять зависимостями построения OSGi?

Мы внедрили среду выполнения OSGi (Equinox) в пользовательское клиент-серверное приложение, чтобы облегчить разработку плагинов, и пока все идет хорошо. Мы используем Eclipse для создания плагинов из-за встроенного редактора манифеста, управления зависимостями и мастера экспорта. Использование Eclipse для сборки менеджера не очень способствует непрерывной интеграции через Hudson.

У нас есть пакеты OSGi, которые зависят от других пакетов OSGi. Я действительно ненавижу строгий порядок сборки в пользовательской компоновке ANT. Мы сделали это в прошлом, и это довольно ужасно. Есть ли какой-либо инструмент построения, который может легко управлять зависимостями OSGi, если они автоматически не разрешают их? Есть ли какие-либо примеры DECENT для этого?

УТОЧНЕНИЕ:

Сгенерированные скрипты сборки можно использовать только через Eclipse. Они требуют ручной работы кусков Eclipse. У нас также есть некоторые стандартные цели, которые не имеют сборки Eclipse, и я не хочу изменять сгенерированный файл, так как я могу регенерировать (я знаю, что могу делать, включая, но я хочу, чтобы все файлы Eclipse gen вместе)

Вот мой макет проекта:

/
-PluginA
-PluginB
-PluginC
.
.
.

При использовании Eclipse PDE каждый плагин имеет манифест, но нет build.xml, поскольку PDE делает это для меня. Трудно автоматизировать процесс, управляемый gui/Hudson. Я бы хотел настроить собственный файл build.xml для сборки, но есть зависимости и проблемы с порядком сборки. Эти проблемы обусловлены файлами манифеста (которые описывают импорт OSGi). Например, PluginC зависит от PluginB, который зависит от PluginA. Они должны быть построены в правильном порядке. Я понимаю, что я могу вручную управлять порядком сборки, я ищу инструмент, помогающий автоматизировать управление зависимостями порядка сборки.

Ответ 1

Закрытие некоторых старых вопросов...

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

В решении участвовали Ant, BND и некоторые пользовательские задачи ant. Различные зависимости пакетов связаны вручную. Мы уже использовали Ant; BND и пользовательские задачи связали все это вместе. Пользовательские задачи просто гарантировали, что наши проекты bnd/eclipse будут синхронизированы.

Ответ 2

Maven2 полностью; имеет плагин Eclipse под названием m2eclipse, чтобы помочь с его управлением, решает точно проблему зависимости, а затем и некоторые. Имеет бесплатную онлайн-книгу в качестве документации.

В частности, рассмотрите многомодульные проекты для объединения многих компонентов вместе, и Maven разработает порядок сборки и зависимости.

Существует также глава посвященная интеграции Eclipse.

И это только Eclipse и Maven, а затем вы получите отличные лакомства для OSGi:

Плагин Apache Felix BND Maven автоматически сгенерирует ваши манифесты или, по крайней мере, поможет вам
проект PAX OPS4J, а их плагины Maven могут помочь в проектах самонастройки, предоставлении пусковых установок и т.д.

И только в основном модель модуля Maven идеально вписывается в модель пакета OSGi. Мы строим и управляем несколькими продуктами с сотнями пакетов, используя Maven уже более 3 лет, и это здорово.

Ответ 3

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

Это проект Eclipse Tools. Он хорошо интегрируется с PDE.

Это означает, что все метаданные, которые мы используем для создания RCP, полезны для Бакминстера для решения и сборки. Например, feature.xml и заголовок Require-Bundle в Manifest.MF,.product.

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

Потребовалось немного усилий, чтобы заставить нашу существующую систему круиз-контроля/ ant работать с ней, хотя они (команда Бакминстера) начали использовать Хадсон для размещения самого проекта. Я считаю, что их установка сборки также доступна для скачивания.

Мы действительно впечатлены этим, несмотря на то, что это относительное младенчество.

Мы также рассмотрели Pax-Construct, но мы не хотели использовать Maven.

В настоящее время мы также изучаем Spring среду тестирования DM для увеличения усилий по тестированию устройств.

Ответ 4

Вторичный Maven2. Посмотрите на плагины Tycho для построения - они используют компилятор Eclipse JDT, поэтому он реализует все правила OSGi во время компиляции, так же, как и во время выполнения Eclipse.

Кроме того, плагины Apache Felix BND также кажутся популярными. Я предпочитаю Tycho, потому что он более тесно объединяет среды разработки Maven и Eclipse.

Ответ 5

Конструкция безголового PDE. Это хорошо задокументировано Eclipse. Если вы создаете плагины Eclipse и хотите сделать это через командную строку, сборка безгласного Eclipse PDE - это путь.

Ответ 6

Не могли бы вы уточнить, где проблема? Вы указываете зависимости пакета OSGi. Это во время выполнения? Или во время компиляции? В первом случае вы должны рассмотреть декларативные услуги (см. Спецификацию OSGi).

Ответ 7

Мы используем Hudson в сочетании с PluginBuilder для создания наших пакетов/плагинов OSGi на основе Eclipse. Это основано на стандартном процессе PDE Eclipse для создания плагинов. Это означает использование Eclipse в качестве компилятора.

Ответ 8

Я использую maven 3.0.2

mvn generate: archetype

select 252 - osgi-archetype
mvn idea:idea

см. http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html

чтобы добавить ваши зависимости в пакет, используйте этот короткий пример в pom.xml

<Export-Package>org.foo.myproject.api</Export-Package>

или

<Import-Package>org.foo.myproject.api</Import-Package>

Ответ 9

Maven не требует подключения к интернету! Используйте ключ -o, ради Христа.