Результаты поиска

В настоящее время у нас есть проект со стандартным расположением репозитория subversion:

/ствол .
/филиал .
/старая карга

Однако, поскольку мы движемся по пути OSGi и модульного проекта, мы закончили с:

/trunk/bundle/main .
/trunk/bundle/modulea .
/trunk/bundle/moduleb ./tags/bundle/main-1.0.0 .
/tags/bundle/main-1.0.1 .
/tags/bundle/modulea-1.0.0

'build' все еще довольно монолитен в том, что он строит все модули последовательно, хотя я начинаю задаваться вопросом, следует ли нам рефакторировать сборку/репозиторий на что-то более похожее:

/bundle/main/trunk .
/bundle/main/tags/main-1.0.0 .
/bundle/main/tags/main-1.0.1 .
/bundle/modulea/trunk .
/bundle/modulea/tags/modulea-1.0.0

В этом шаблоне я бы представил, что каждый модуль строит себя и хранит свой двоичный файл в репозитории (maven, ivy или другой путь самого репозитория subversion).

Существуют ли руководящие принципы или 'best-practices' над макетами проектов, как только они становятся модульными?

Что делает module/service/bit функциональности приложения особенно хорошим кандидатом для модуля OSGi?

Я заинтересован в использовании OSGi в своих приложениях. Мы являемся магазином Java и довольно широко используем Spring, поэтому я склоняюсь к использованию динамических модулей Spring для платформ обслуживания OSGi(tm). Я ищу хороший способ включить немного OSGi в приложение в качестве пробной версии. Кто-нибудь здесь использовал эту или подобную технологию OSGi? Есть ли какие-то подводные камни?

@Nicolas-Спасибо, я это уже видел. Это хороший учебник, но я больше ищу идеи о том, как сделать мой первый "real" OSGi bundle, в отличие от примера Hello World.

@david-Спасибо за ссылку! В идеале, с приложением greenfield, я бы спроектировал все это, чтобы быть динамичным. Однако прямо сейчас я ищу, чтобы ввести его в небольшой фрагмент существующего приложения. Предполагая, что я могу выбрать любую часть приложения, какие факторы следует учитывать, чтобы сделать эту часть лучше или хуже в качестве 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. Они должны быть построены в правильном порядке. Я понимаю, что могу вручную управлять порядком сборки, я ищу инструмент, который поможет автоматизировать управление зависимостями порядка сборки.