Управление комплектами команд

Question

Мы переносим наше приложение на платформу OSGI (все разработчики используют Eclipse) и пытаемся определить лучшую командную среду для разработки наших пакетов.

У нас есть пакеты из нескольких источников:

1. Обычные пакеты из проектов, таких как Orbit или Apache, которые управляются сторонними организациями.
2. Пакеты, которые упаковывают специфичные для домена файлы JAR.Мы управляем этими пакетами внутренне.
3. Пакеты, предоставляемые другими командами компании, которые доступны только для нас для чтения
4. Пакеты, предоставляемые нашей командой, которые содержат активно разработанный исходный код.

В случаях 1-3 мы хотели бы установить в нашей локальной среде Eclipse IDE и предоставить целевую платформу.Мне кажется, что мы просто создадим репозиторий p2, который предоставит все пакеты в 1-3 и предоставит их в качестве целевого определения.Не стесняйтесь указать лучшее решение, если оно есть.

Пакеты, содержащиеся в случае 4, хранятся в репозитории Mercurial.Хотя определение цели выглядит так, как будто оно может захватывать пакеты из нескольких источников, оно не рассматривает вопрос о том, как включать пакеты из (d) vcs.

Какова лучшая практика?Размещаем ли мы информацию о наших пакетах (d) vcs на целевой платформе и просто заставляем разработчиков загружать правильные пакеты вручную?Также, как нам управлять изменениями в определении цели?Нужно ли всем писать по электронной почте, когда они меняются, или есть более элегантное решение?

Спасибо за помощь.

Answer 1

Я использую eclipse, m2eclipse, maven-bundle-plugin , subversion, nexus и hudson , и это работает как шарм, особенно вкомандная среда.

Автоматизация генерации manifest.mf очень важна в OSGi, потому что выполнение этого вручную очень подвержено ошибкам.Для этого используйте bnd (автоматизировано bndtools или maven-bundle-plugin)

Pax Construct может помочь в создании полной среды выполнения OSGi.

Answer 2

место, чтобы поделиться целью с разработчиком.Недостаток в том, что у нас есть артефакты в нашем SVN!Но репозиторий p2 звучит намного лучше.Когда каждый devloper активирует автообновление, он будет проинформирован о появлении обновлений.Я думаю, что мы должны попробовать это в будущем в моей компании.

Наш активно разработанный исходный код, которым мы делимся Наборы командных проектов (* .psf).Это один текстовый файл, который содержит всю информацию о репозитории проектов затмений exportet.Попробуйте это в вашей Eclipse IDE с File -> Export -> Team -> Team Project Set.Есть ли какие-либо изменения в наборе проектов? На самом деле мы отправляем электронное письмо нашим разработчикам.Я думаю, что более элегантный способ - поделиться им через репозиторий p2.

Надеюсь, это помогает и извините за мой плохой английский!

Answer 3

Спасибо всем, кто ответил за понимание того, как другие решают эту проблему.

Мы закончили с Бакминстер . Это позволяет нам быстро описать, где находятся все наши пакеты (случаи 1-3 из репозиториев p2, случай 4 из mercurial) и обеспечивает настройку одним кликом пустых рабочих областей через CQuery. Он также хорошо интегрируется с Hudson и упрощает настройку CI по сравнению со сборкой PDE, которую я использовал в других проектах.

Answer 4

Лучше использовать Apache Maven [1], если вы хотите использовать независимую от Eclipse среду.

Плюсы :

• Все ваши артефакты будут храниться в одном репозитории Maven.Вы можете использовать такие инструменты, как Artifactory [2], чтобы создавать репозиторий Maven для всей команды и делиться им (во избежание проблем со сторонними артефактами)
• доступно множество руководств по OSGi Maven, которые помогут вам найти ответыпочти на все ваши вопросы
• Eclipse очень хорошо поддерживает Maven с помощью плагина m2Eclipse [3]
• IDE в этом случае не так важен.Члены вашей команды могут выбрать любой (даже vi или emacs)

Минусы :

• , вам нужно найти репозитории Maven для всех ваших артефактов.Для артефактов Eclipse это не так просто, но вы можете попытаться найти их здесь: [4]
• изменить структуру вашего проекта на основе требований Maven
• потратить некоторое время на понимание и использование шаблонов Maven (для OSGi)

[1] - http://maven.apache.org/

[2] - http://www.jfrog.org/products.php

[3] - http://m2eclipse.sonatype.org/

[4] - http://build.eclipse.org/helios/hybrid/final/

С уважением, Дмитрий