Как я могу управлять зависимостями построения 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:
И только в основном модель модуля 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, ради Христа.
