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

Question

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

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

РАЗЪЯСНЕНИЯ:

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

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

/
-PluginA
-PluginB
-PluginC
.
.
.

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

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

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

В настоящее время мы также рассматриваем среду тестирования Spring DM , чтобы расширить возможности модульного тестирования.

Answer 6

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

Answer 7

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

Mvn Generate: архетип

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>

Answer 8

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

Answer 9

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