Это привело к вопросу о том, хорошо ли интегрированы Apache Maven и IBM Rational ClearCase. Подумал, что мне нужно написать то, что я обнаружил - потребуются различные правки, но в конечном итоге я добавлю все, что я надеюсь.
ClearCase - ClearCase версии 7.0.1.2.
Maven - Все из Веб-сайт Maven.
Hudson - Версия 1.307 скачивается прямо с Сайт Hudson
Я установил все версии Maven2 в VOB, «сложенный», т.е. я добавил версию 2.0 - пометил ее, заблокировал метку - затем добавил 2.0.1 поверх.
Чтобы предотвратить появление посторонних файлов, я использовал флаг -rnname в clearfsimport.
Таким образом, я мог просто использовать метку, чтобы указать версию Maven, к которой я хотел получить доступ, в моей спецификации конфигурации, но все же сохранить тот же путь для исполняемого файла maven - / maven / bin / mvn.
После установки всех версий у меня не возникло проблем с запуском Maven оттуда через Динамический View. Репозитории загружаются из внутренней установки Nexus в домашний каталог пользователей как обычно - и это избавляет от любых проблем с возвратом и уходом.
Преимущество сохранения инструмента в системе управления версиями состоит в том, что вы можете установить настройки для всей компании (например, указание на внутренний репозиторий), а затем запустить этот единственный экземпляр Maven из VOB на любой платформе, которая сохраняет настройки, которые вы изначально установили!
В проектах Maven я сохранял только каталог src и pom.xml в системе управления версиями, так как все остальное впоследствии может быть автоматически сгенерировано.
У меня не было проблем с настройкой Hudson для работы с ClearCase Dynamic Views. Все, что потребовалось, - это символическая ссылка из рабочего каталога Hudson на корень представления (в данном случае / view / xxx). Подключаемый модуль ClearCase успешно запустил ct lshistory, чтобы определить, были ли какие-либо изменения в ветви интеграции, в которую сливаются разработчики.
Я написал небольшой скрипт для настройки исходной среды для задания - только символическая ссылка config.xml и динамического представления - так, чтобы правильный вид был указан в задании, а начальные настройки были правильными. Любые последующие улучшения, внесенные пользователями, были затем изменениями в шаблоне по умолчанию, а не самими настройками.
В общих настройках Hudson я использовал переменную среды $ CLEARCASE_VIEW, чтобы задать путь к исполняемому файлу Maven. Таким образом, версия Maven зависела от версии, установленной в спецификации конфигурации, а не от той, которую они выбрали в Hudson.
Это избавляет от лишнего администрирования как со стороны меня (администратора), так и со стороны моих пользователей.
Я установил Sonatype Nexus в качестве диспетчера внутреннего репозитория - в первую очередь потому, что я прочитал в Блог Sonatype, что Hudson будет более интегрирован с Nexus, и мы можем также быть готовы к новым улучшениям в будущем. Когда я настроил его и попробовал, я также считал, что он более подготовлен для большой коммерческой среды, потому что вы можете настроить группы в диспетчере репозитория, чтобы они были более гибкими - полезными для большого количества проектов.





Я не использую этот SCM, но есть Плагин Maven2, называемый SCM, который обрабатывает Clearcase.
У меня есть несколько репозиториев Maven за пределами ClearCase для некоторых сторонних библиотек.
Но я никогда не использовал Maven с ClearCase, поскольку они следуют другой логике (Maven нужны подписанные имена для файлов, например myfile-1.2.jar, тогда как ClearCase может хранить только myfile.jar и записывать тот факт, что это версия с меткой 1.2)
Это могло измениться с Плагин Maven2 ClearCase, сообщенным Роментаз, но все еще есть некоторые ошибки в этом новом продукте, как показано этим нить, когда его запускают во второй раз, не распаковывая pom-файл. Maven отлично справляется с оформлением заказа, но не может выполнить следующий шаг.
INFO Checking out file: /opt/viewstore/common/maven/my_lf_ss/vobs/test_alm/LF_Build/pom.xml
INFO ERROR BUILD FAILURE
INFO INFO Unable to enable editing on the POM
Provider message:
The cleartool command failed.
Command output:
cleartool: Error: Element "/opt/viewstore/common/maven/my_lf_ss/vobs/test_alm/LF_Build/pom.xml" is already checked out to view "my_lf_ss".
myfile-1.2.jar -> myfile.jar @@ / main / 2
Что ж, мы не хотели вводить этот дополнительный шаг, учитывая огромное количество файлов, которыми мы должны управлять, и тот факт, что мы не всегда находимся в среде unix (хотя символическая ссылка «возможна» в Windows). Но вы правы, это возможно.
У меня был тимбилдинг с Maven 2 и Clearcase в качестве системы контроля версий. Мы использовали Archiva в качестве репозитория для собранных артефактов, поэтому команде разработчиков не нужно было использовать плагин SCM.
Однако сервер непрерывной интеграции был Continuum и полагался на информацию SCM в POM. У нас были проблемы с Clearcase SCM, получавшим снимки состояния с использованием стратегии ветвления out. Одному из моих разработчиков пришлось настроить SCM-код Clearcase, чтобы он работал с нашими ветками. Мы оба ушли, прежде чем добрались до его исправления.
Так как насчет использования символических ссылок для ссылки на правильную версию файла в Clearcase?