Полностью автоматизируйте процедуру релиза с помощью плагинов релиз+версия

Было бы здорово, если бы сообщество гуру Maven помогло мне со следующей задачей.

Я хотел бы автоматизировать процесс выпуска модуля Maven в Hudson таким образом, чтобы процесс выпуска выполнялся в пакетном режиме (не нужно ничего запрашивать с консоли). В настоящее время я использую общие шаги release:prepare<preparationGoals>versions:update-parent clean verify</preparationGoals> для обновления родителя до последней версии перед фиксацией) + release:perform. Однако я хотел бы, чтобы Maven сделал следующее:

Где-то на этапе подготовки:

  • Для всех зависимостей, которые соответствуют groupId текущего модуля и родительского, замените -SNAPSHOT на выпущенную версию (например, versions:use-releases -Dincludes=???).

Через некоторое время после освобождения:

  • Для всех зависимостей, которые соответствуют groupId текущего модуля и родительского, замените версию выпуска на -SNAPSHOT версию (например, versions:use-latest-snapshots ...).

Пример:

<parent>
    <groupId>org.mycompany.myproject</groupId>
    <artifactId>myproject-parent</artifactId>
    <version>1.0-SNAPSHOT</version>
</parent>

<dependency>
    <groupId>${project.groupId}</groupId>
    <artifactId>myproject-api</artifactId>
    <version>1.1-SNAPSHOT</version>         
</dependency>

перед тем, как модуль помечен, преобразуется в:

<parent>
    <groupId>org.mycompany.myproject</groupId>
    <artifactId>myproject-parent</artifactId>
    <version>1.0</version>
</parent>

<dependency>
    <groupId>${project.groupId}</groupId>
    <artifactId>myproject-api</artifactId>
    <version>1.1</version>          
</dependency>

и после успешного освобождения преобразуется в:

<parent>
    <groupId>org.mycompany.myproject</groupId>
    <artifactId>myproject-parent</artifactId>
    <version>1.1-SNAPSHOT</version>
</parent>

<dependency>
    <groupId>${project.groupId}</groupId>
    <artifactId>myproject-api</artifactId>
    <version>1.2-SNAPSHOT</version>         
</dependency>

Я чувствую, что ему нужна смесь

versions:use-releases scm:commit release:prepare release:perform versions:use-latest-snapshots scm:commit

но я не уверен, что это лучший способ сделать это. Особенно было бы неплохо иметь как можно меньше коммитов: сложность в том, что reparationGoals запускаются после -SNAPSHOT проверки версии.

Описанный проект не является многомодульным в том смысле, что родительский POM не ссылается на свои дочерние элементы через <modules>. Структура СКМ следующая:

 .
 |
 +-- myproject-parent
 |   +-- pom.xml
 +-- myproject-api
 |   +-- pom.xml
 +-- myproject-impl
     +-- pom.xml

Зависимости:

myproject-api → myproject-parent
myproject-impl → myproject-parent
myproject-impl → myproject-api

Родительский POM проекта (myproject-parent) будет выпускаться редко и поэтому будет выпущен первым. Затем myproject-api (при необходимости) и затем myproject-impl.


person dma_k    schedule 10.05.2012    source источник


Ответы (1)


Простая проблема, с которой вы столкнулись, заключается в том, что у вашего родителя номер версии отличается от номера версии вашего дочернего элемента, что является неправильным способом сборки с несколькими модулями. Сборка с несколькими модулями предназначена для того, чтобы иметь ряд связанных модулей, которые имеют один и тот же процесс выпуска, из которого следует, что они имеют одинаковый номер версии. Если вы следуете этому правилу, вам не нужен плагин версий, вы делаете релиз только через release:prepare и release:perform Вот и все.

Обновление: после дальнейшего обсуждения я бы предложил настроить новый набор заданий Hudson, которые содержат зависимости между модулями (нисходящие/восходящие зависимости) и выполнить выпуск для каждого задания hudson, которое запускает следующее в строке заданий и так далее. Это также требует наличия отдельных модулей и отдельных областей в системе контроля версий. В противном случае эта битва с Мавеном будет проиграна и осложнит жизнь.

person khmarbaise    schedule 11.05.2012
comment
Я не могу с вами согласиться. У нас плоская модульная структура: это единственный способ сделать их разделенными и независимыми в Hudson (иначе сбой теста в подмодуле приведет к сбою сборки всего проекта). Некоторые модули (например, родительский POM) изменяются редко: их не нужно выпускать. Другие (например, модель) будут выпущены несколько раз. И ваш совет не работает, если у меня есть зависимости между двумя многомодульными проектами. Кроме того, даже для многомодульной сборки у меня нет доказательств того, что release:prepare заменит -SNAPSHOT зависимости будущими версиями выпуска. - person dma_k; 11.05.2012
comment
Во-первых, я могу сказать, что это хорошо, если тесты провалятся, вся сборка провалится, потому что что-то не так. Вопрос в том, почему вам нравится, когда они разделены в Гудзоне? Либо это многомодульная сборка, либо нет. Кроме того, если ваш родительский pom меняется редко, так что это может быть отдельный модуль, который имеет свой собственный цикл выпуска, и вам нужно его выпустить, потому что он используется другими как зависимость/родитель. Если у вас есть зависимости между модулями, что будет идеально работать в многомодульной сборке. Я могу порекомендовать посмотреть здесь: github.com/khmarbaise/javaee в качестве примера. - person khmarbaise; 11.05.2012
comment
Во-первых, я могу сказать, что это хорошо, если тесты провалятся, вся сборка провалится, потому что что-то не так. Это не всегда удобно. В нашем проекте небольшие группы разработчиков работают над собственным модулем. Каждый модуль имеет свой собственный список уведомлений по электронной почте для отправки электронных писем при сбое сборки / восстановлении после сбоя. Таким образом, лица X и Y отвечают за модули A и B. - person dma_k; 14.05.2012
comment
Вопрос в том, почему вы хотите, чтобы они были разделены в Hudson? Каждое задание Hudson имеет собственную историю сборок, историю матриц покрытия кода и резервное копирование артефактов. Вы когда-нибудь использовали CI в корпоративной среде? Если это так, вы должны знать правило: если CI терпит неудачу, никакие коммиты не допускаются, и команда должна сначала исправить CI. Разделение большого модуля на более мелкие части дает команде возможность продолжить разработку независимого модуля, который не дал сбоев. - person dma_k; 14.05.2012
comment
Либо это многомодульная сборка, либо нет. Проект, который я описываю, не является многомодульным проектом в том смысле, что родительский pom не ссылается на свои дочерние элементы через раздел <modules>. Я обновил вопрос. Кроме того, если ваш родительский pom меняется редко, так что это может звучать как отдельный модуль, у которого есть собственный цикл выпуска, и вам нужно выпустить его, потому что он используется другими как зависимость/родитель. Да, это так. именно такая ситуация: родительский POM выпускается отдельно. - person dma_k; 14.05.2012
comment
Если у вас есть зависимости между модулями, что будет идеально работать в многомодульной сборке. Могу порекомендовать посмотреть здесь Ваш проект имеет чистую структуру, как проекты Spring или Hibernate, которые выпускаются как один проект. Однако моя ситуация такая же, как javax.xml.bind:jaxb-api+com.sun.xml.bind:jaxb-impl+net.java:jvnet-parent: каждый из них выпускается отдельно. Ваша ситуация проще, потому что вы ссылаетесь на версию через ${project.version}, которая унаследована от вашего POM. - person dma_k; 14.05.2012
comment
В вашем случае maven-release-plugin заменит версию POM <version>1.0.3-SNAPSHOT</version> на <version>1.0.3</version>перед фактическим выпуском, потому что вы выполняете многомодульную сборку. Вы вводите версии из консоли или используете autoVersionSubmodules=true? Также не помогает ваше обновление в ответе: как настроить задания и триггеры - понятно, как делать релиз - не понятно. Будет ли maven-release-plugin обновлять версии до последних выпущенных артефактов? (P.S. извините за нарезку ответа, я нажал на ограничение комментариев) - person dma_k; 14.05.2012