Лучший способ автоматически проверить и скомпилировать проекты Eclipse с Муравьем в Гудзоне или другим инструментом CI?

Я попробовал и Круиз-контроль (CC) и Гудзон для нашего решения CI. Мы (как компания) выбрали Гудзон. Но для Вашего вопроса "Делает сборку проекта Eclipse поддержки CC" ответ, не насколько я знаю. CC поддерживает намного более различные инструменты сборки и Системы управления исходным кодом, но немного более трудно настроить и использовать. Что касается Гудзона, более просто настроить и использовать его. Мы разработали наши пользовательские плагины и для CC и для Гудзона для частей нашего цикла сборки, который они не обеспечивают, как. Что касается разработки плагинов, если Вы знаете / используют Знатока, Гудзон более прост также. Но если Вы не знакомы Знатоку, сначала необходимо изучить основное использование знатока для успешной разработки Гудзонского плагина. Но после того как Вы понимаете основное использование знатока, разработку плагинов, тест и даже отлаживаете, более просто в Гудзоне.

Для Вашей определенной проблемы я могу думать о решении, которое использует плагины Eclipse также. Можно разработать собственный плагин Eclipse, который, например, получает psf файлы от (настраиваемой) папки, и используйте внутренности Eclipse для обработки их psf's. Я подразумеваю, что можно использовать существующие исходные коды Eclipse, который берет psf файл, контроль это - определения проекта, и скомпилируйте эти проекты. Этот ваш плагин Eclipse может иметь предпочтительную страницу (к которому можно получить доступ Eclipse-> Окно-> Предпочтения), и настройте, какую папку это будет использовать для поиска psf файлов. Ваш плагин Eclipse должен также иметь способ запустить psf, обрабатывающий без взаимодействия с пользователем. Для этого можно использовать IPC для инициирования процесса. Я подразумеваю, что Ваш плагин Eclipse может прислушаться к порту, и можно записать другое JAVA-приложение, которое соединится с плагином через этот порт и инициирует его процесс. Что касается части CI, можно использовать или CC или Гудзон и использовать их внешнюю поддержку выполнения процесса. При использовании Windows можно записать bat-файл (для Linux sh файл), что первый launchs Eclipse, которому установили плагин. Затем это запускает Ваше JAVA-приложение, которое будет общаться с Вашим плагином Eclipse для инициирования процесса. От Вашего инструмента CI необходимо будет выполнить летучую мышь / sh файл для инициирования процесса.

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

Я решаю точно эту проблему с помощью Гудзона, муравья и плюща. Я следую за шаблоном, продемонстрированным Clark в Прагматической Автоматизации Проекта (он не демонстрирует проблемы зависимости и решения, и он использует CruiseControl, а не Гудзон.)

У меня есть рукописный файл типа "build" муравья (мы называем его "cc-build.xml" из-за наших корней CruiseControl.) Этот файл ответственен за обновление рабочей области для проекта из репозитория CM и маркировки содержания для дальнейшего использования. Это затем руки прочь от управления к другому рукописному файлу типа "build" муравья (build.xml), который предоставлен разработчиками каждого проекта. Этот проект ответственен за традиционные шаги сборки (компиляция, упаковка, и т.д.) Это требуется выложить устанавливаемые артефакты, отчеты о модульном тесте, и т.д., к Гудзонскому каталогу артефактов. Именно мой опыт автоматически генерировал файлы типа "build" (Eclipse, или другой подобный IDE) никогда не будет рядом с получением этого достаточно устойчивого для использования в сценарии CI.

Кроме того, это использует плющ для разрешения его собственных зависимостей. Плющ поддерживает точно указанные версии зависимости (например, "версия 1.1 использования"), и это поддерживает "нечеткие версии" (например, "версия 1.1 использования +", или "используют последнюю версию в состоянии интеграции".) Наши проекты обычно начинают указывать очень "нечеткую" версию для внутренних проектов при продолжающейся разработке, и поскольку они рядом с точкой выпуска, они "замораживают" версию зависимости так, чтобы материал прекратил перемещаться под ними.

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

Наконец, каждый проект в Гудзоне настроен, чтобы иметь триггер сборки, который вызывает восстанавливание, когда любой из его зависимых проектов успешно создает. Это заставляет их быть созданными снова с (возможно) новой зависимой версией плюща.

Стоит отметить, что, после того как Вы будите этот и выполнение, последовательную автоматизированную "маркировку" или "метки" исходных данных автоматизированной сборки, будет очень важным для Вас - иначе диагностирующий проблемы постсборки, собирается привести к необходимости распутать вложенное множество шершня для нахождения первоисточника.

Получение всей этой установки для нашей среды приложило довольно мало усилий (прежде всего, в установке репозитория плюща и файлов типа "build" муравья), но это заплатило за себя много раз при сохраненных головных болях в ручном управлении зависимостями и уменьшило усилие по поиску и устранению неисправностей.