У нас есть несколько продуктов, которые имеют много общего кода и которые должны поддерживаться несколько версий назад.
Чтобы справиться с этим, мы используем много проектов Eclipse, некоторые содержат библиотеки jar, а некоторые содержат общий исходный код (в нескольких проектах, чтобы избежать гигантской кучи с многочисленными зависимостями, и при этом возможность компилировать все с нуля, чтобы гарантировать, что источник и двоичные файлы соответствуют). Мы управляем этими проектами с помощью projectSet.psf, поскольку они могут напрямую вытягивать все проекты из CVS и оставлять полностью подготовленное рабочее пространство. Мы не занимаемся сборкой муравьев напрямую и не используем maven.
Теперь мы хотим иметь возможность поместить все эти проекты и их различные версии в инструмент непрерывной интеграции - мне нравится Хадсон, но это всего лишь вопрос вкуса - что по сути означает, что нам нужно получить автоматический способ проверки проекты в новую рабочую область и скомпилируйте исходные папки, как описано в файлах проекта в каждом проекте. Хадсон не предлагает такой подход к созданию проекта, поэтому я обдумывал, как лучше всего к этому подойти.
Идеи были
- Найдите или напишите плагин / конвертер ant, который понимает файлы projectSet.psf и сопоставляет их с cvs-checkout и компилирует теги.
- Создайте файлы build.xml из Eclipse и используйте их. Я попробовал это и обнаружил, что результат получился многословным и с абсолютными местоположениями, что не годится для автоматических инструментов, помещающих файлы туда, куда они хотят.
- Напишите плагин Hudson, который понимает файл projectSet.psf для получения конфигурации и ее построения.
- Просто откусите пулю и вручную создайте и обновите конфигурацию CI всякий раз, когда что-то ломается - мне это не нравится:)
Мне бы очень хотелось услышать об опыте других людей, чтобы я мог решить, как к этому подойти.
Редактировать: другим вариантом может быть использование CI, который лучше знает проекты Eclipse и / или наборы проектов. Мы не религиозны - это просто вопрос запуска вещей без необходимости делать все самим. Будет ли круиз-контроль лучшим вариантом? Другие
Редактировать: Обнаружено, что ant4eclipse имеет средство "Team Project Set". http://ant4eclipse.sourceforge.net/
Редактировать: Использовать ant4eclipse и ant-contrib ant extensions для создания полного рабочего пространства в виде sjgned runnable jar-файла, похожего на средство Runnable Jar в Eclipse 3.5M6. Я все еще полагаюсь на Eclipse, чтобы создать начальную пустую рабочую область и извлечь ProjectSet, так что это следующее препятствие.
Редактировать: Закончено двойной конфигурацией, а именно то, что Хадсон извлекает из CVS тот же набор модулей, который указан в файле ProjectSet.pdf (который должен иметь тот же тег), в результате чего они располагаются рядом друг с другом. Тогда ant4eclipse хорошо работает с файлом projectSet.psf, встроенным в основной модуль. Предостережение: список модулей в Hudson необходимо обновить вручную, и, по-видимому, впоследствии потребуется ручная очистка рабочего пространства, чтобы Hudson «обнаружил», что сейчас существует больше проектов, чем раньше. Теперь это работало хорошо для нас в течение пары месяцев, но было довольно утомительно, чтобы все работало внутри файла ant.
Редактировать: «Использование командных проектов» с ant4eclipse и Ctrl-A, Ctrl-C на панели проектов с Ctrl-V в проектах CVS в Гудзоне оказалось достаточно хорошим для нас, чтобы жить (для зрелые проекты это очень редко меняют). Я жду релиза ant4eclipse 1.0 - http://www.ant4eclipse.org/,, который в настоящее время находится на этапе 2 - чтобы увидеть, сколько доморощенной функциональности можно заменить вещами ant4eclipse.
Редактировать: ant4eclipse по состоянию на 20100609 в M4, поэтому график в http://www.ant4eclipse.org/node?page=1 несколько смещается.
Edit: мой вывод после использования нашего подхода ant4eclipse в течение более длительного периода заключается в том, что скрипт сборки становится очень грубым и его трудно поддерживать. Также средство Team ProjectSet (которое ant4eclipse использует для поиска проектов), которое хорошо работает для репозиториев на основе CVS, но не после того, как мы перешли на git (что само по себе очень важно). Новые проекты, скорее всего, будут основаны на Maven, так как это имеет хорошую поддержку в Jenkins.