My<cod/>.net
Как я могу управлять OSGi зависимостями сборки?
Мы встроили OSGi runtime (Equinox) в наше пользовательское клиент-серверное приложение, чтобы облегчить разработку плагинов, и до сих пор все идет отлично. Мы использовали Eclipse для создания плагинов благодаря встроенному редактору манифестов, управлению зависимостями и мастеру экспорта. Использование Eclipse для управления сборками не очень способствует непрерывной интеграции через Hudson.
У нас есть OSGi пучков, которые зависят от других OSGi Пучков. Я бы очень не хотел жестко кодировать порядок сборки в пользовательской сборке ANT. Мы сделали это в прошлом, и это довольно ужасно. Существует ли какой-либо инструмент сборки, который может EASILY управлять OSGi зависимостями, если не разрешать их автоматически? Есть ли какие-нибудь DECENT примера того, как это сделать?
CLARIFICATION:
Созданные сценарии сборки можно использовать только через Eclipse. Они требуют ручного запуска частей Eclipse. У нас также есть некоторые стандартные цели, которых не будет у сборки Eclipse, и я не хочу изменять созданный файл, так как я могу регенерировать (я знаю, что могу сделать это, но я хочу избежать файла Eclipse gen все вместе)
Вот мой макет проекта:
/
-PluginA
-PluginB
-PluginC
.
.
.
При использовании Eclipse PDE каждый плагин имеет манифест, но не build.xml, так как PDE делает это для меня. Трудно автоматизировать процесс, управляемый графическим интерфейсом w/ Hudson. Я хотел бы настроить свой собственный build.xml для сборки каждого, BUT есть зависимости и проблемы с порядком сборки. Эти проблемы вызваны файлами Манифеста (которые описывают OSGi импорта). Например, PluginC зависит от PluginB, который зависит от PluginA. Они должны быть построены в правильном порядке. Я понимаю, что могу вручную управлять порядком сборки, я ищу инструмент, который поможет автоматизировать управление зависимостями порядка сборки.
Maven2 all the way; имеет плагин Eclipse под названием m2eclipse , который помогает управлять им, решает именно проблему зависимости, а затем и некоторые другие. Имеет бесплатную онлайн-книгу в качестве документации .
В частности, посмотрите на многомодульные проекты для объединения многих компонентов вместе и попросите Maven разработать порядок сборки и зависимости.
Существует также глава, посвященная интеграции Eclipse .
А это всего лишь Eclipse и Maven, далее вы получите несколько крутых вкусностей для OSGi:
- Плагин Apache Felix BND Maven автоматически сгенерирует ваши манифесты или, по крайней мере, поможет вам
- Проект PAX OPS4J и их Плагины Maven могут быть отличным помощником в проектах bootstrapping, предоставляя пусковые установки и т. д
И просто принципиально, модель модуля Maven идеально подходит для модели OSGi bundle. Мы строим и управляем несколькими продуктами с сотнями пакетов с использованием Maven уже более 3 лет, и это здорово.
Прикомандирования Maven2. Посмотрите на Плагины Tycho для сборки-они используют компилятор Eclipse JDT, поэтому он реализует все правила OSGi во время компиляции, так же как и Eclipse во время выполнения.
Кроме того, Плагины Apache Felix BND также кажутся популярными. Я предпочитаю Tycho, потому что он более тесно объединяет среды разработки Maven и Eclipse.
Мы используем Бакминстер . Это платформа build and assembly, которая заботится о разрешении зависимостей, извлечении из различных репозиториев, сборке и упаковке продукта.
Это проект Eclipse Tools. Он хорошо интегрируется с PDE.
Это означает, что все метаданные, которые мы используем для построения RCP, полезны для решения и построения Buckminster. Например, feature.xml и заголовок Require-Bundle в поле Manifest.MF, .товар.
Теперь у нас нет никаких сценариев сборки в каждом bundle; теперь у нас есть одна сборка для каждого продукта. Бакминстер заботится о графе зависимостей.
Потребовалось немного усилий, чтобы заставить нашу существующую систему cruise-control/ant работать с ней, хотя они (команда Buckminster) начали использовать Hudson для размещения самого проекта. Я считаю, что их настройка сборки также доступна для скачивания.
Мы действительно впечатлены им, несмотря на то, что он находится в относительном младенчестве.
Мы также заглянули в Pax-Construct , но не хотели использовать Maven.
Мы также в настоящее время рассматриваем платформу тестирования Spring DM для увеличения усилий по модульному тестированию.
Закрываю некоторые старые вопросы...
Наша настройка не была благоприятна для maven из-за отсутствия подключения к сети и времени. Я знаю, что есть офлайн-настройки maven, но это было слишком много, учитывая время. Надеюсь, мы сможем использовать правильную настройку, когда у нас будет время для реорганизации процесса сборки.
Решение включало в себя Ant, BND и некоторые пользовательские задачи ant. Различные зависимости bundle управляются вручную. Мы уже использовали Ant; BND и настраиваемые задачи связывали все это вместе. Пользовательские задачи просто убедились, что наши проекты bnd/eclipse были синхронизированы.
Я использую maven 3.0.2
МВН generate:archetype
select 252 - osgi-archetype
mvn idea:idea
увидеть http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
чтобы добавить свои зависимости в bundle, используйте этот короткий пример в pom.xml
<Export-Package>org.foo.myproject.api</Export-Package>
или
<Import-Package>org.foo.myproject.api</Import-Package>
Мы используем Hudson в сочетании с PluginBuilder для построения нашего Eclipse-based OSGi bundles/plugins. это строится на стандартном PDE процессе Eclipse для построения плагинов. Это означает использование Eclipse в качестве компилятора.