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

Question

Мы внедрили среду выполнения 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. Они должны быть построены в правильном порядке. Я понимаю, что могу вручную управлять порядком сборки, я ищу инструмент, помогающий автоматизировать управление зависимостями порядка сборки.

Answer 1

Закрывая старые вопросы ...

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

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

Answer 2

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

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

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

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

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

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

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

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

Answer 3

Maven2 полностью; имеет плагин Eclipse под названием m2eclipse, чтобы помочь с его управлением, решает точно проблему зависимости, а затем и некоторые. Имеет free online book as documentation.

Специально посмотрите на multi-module projects для объединения многих компонентов вместе, и Maven разработает порядок сборки и зависимости.

Существует также chapter on the Eclipse integration.

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

• Apache Felix BND Maven plugin будет автоматически создавать свои манифесты или, по крайней мере, поможет вам
• PAX OPS4J project и их Maven плагины могут оказать большую помощь в проектах самонастройки, предоставляя пусковые установки и т. д.

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

Answer 4

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

Answer 5

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

Answer 6

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

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

Answer 7

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

Answer 8

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

МВН генерации: архетип

select 252 - osgi-archetype 
mvn idea:idea 

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

добавлять зависимости в использовании расслоении этот короткий пример в ПОМ.XML

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

или

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

Answer 9

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