Предотвращение конфликта версий репозитория maven при использовании ветвей функций

Как насчет следующего подхода:

• Используйте buildnumber-maven-plugin, чтобы получить информацию из git и заполнить определенные свойства Maven (нас конкретно интересует в свойстве scmBranch (то есть текущей ветке git)
• Используйте build-helper-maven-plugin, чтобы проверить, находимся ли мы в функциональной ветке или нет (через a регулярное выражение, за исключением известных ветвей, таких как master, develop и т. д.) и заполните (или нет) новое свойство Maven, скажем, branch.classifier
• Используйте maven-jar-plugin, чтобы установить классификатор для сгенерированных артефактов на основе того, что установлен предыдущий шаг, то есть с использованием нового свойства branch.classifier: если оно пусто, классификатор не применяется (поведение по умолчанию, например, применяется к ветке develop); в противном случае будет динамически применяться классификатор, названный в честь текущей ветви.

Вот минимальный пример:

<build>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>buildnumber-maven-plugin</artifactId>
            <version>1.4</version>
            <executions>
                <execution>
                    <phase>validate</phase>
                    <goals>
                        <goal>create</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>build-helper-maven-plugin</artifactId>
            <version>1.10</version>
            <executions>
                <execution>
                    <id>regex-property</id>
                    <goals>
                        <goal>regex-property</goal>
                    </goals>
                    <configuration>
                        <name>branch.classifier</name>
                        <value>${scmBranch}</value>
                        <regex>(^develop)|(^master)|(^release.*)</regex>
                        <replacement></replacement>
                        <failIfNoMatch>false</failIfNoMatch>
                    </configuration>
                </execution>
            </executions>
        </plugin>
        <plugin>
            <artifactId>maven-jar-plugin</artifactId>
            <version>3.0.2</version>
            <configuration>
                <classifier>${branch.classifier}</classifier>
            </configuration>
        </plugin>
    </plugins>
</build>

Фрагмент ниже в основном динамически заполняет свойство scmBranch, затем устанавливает branch.classifier его значение, только если оно отличается от develop, master или release*, а затем устанавливает его как классификатор.

Основные преимущества этого подхода:

• Никакие изменения pom не будут применены, поэтому проблем со слиянием не возникнет.
• Никаких конфликтов на Nexus, работающих над одной и той же версией проекта, но в разных ветках: классифицированный артефакт будет иметь разные Координаты Maven, то есть GAV (groupId, ArtiftId, версия) становится уникальным GAVC (+классификатор)
• На самом деле это осмысленное использование атрибута classifier артефакта:

  #P5#

• Сгенерированный артефакт будет динамически отличаться в Nexus в соответствии с его исходной ветвью, следовательно, будет иметь неявную прослеживаемость: никакого вмешательства со стороны разработчиков (не подвержено ошибкам, неявное соглашение), никакого вмешательства со стороны задания CI (более простое обслуживание), полностью прозрачного
• Используя классификаторы, будет проще использовать артефакты, сгенерированные веткой, в качестве зависимости от maven (например, в случае проекта библиотеки): я хочу использовать зависимость, которая в настоящее время разрабатывается в ветке xxx

Примеры
Таким образом, будут созданы следующие артефакты:

• При работе с develop: например. project-1.0.0-SNAPSHOT.jar (пустой классификатор, поэтому не применяется, так как обрабатывается регулярным выражением)
• При работе с featureA: например. project-1.0.0-SNAPSHOT-featureA.jar
• При работе с hotfix-JIRA123: например. project-1.0.0-hotfix-JIRA123.jar
• При работе над release-sprint42: это зависит от вас, я добавил этот случай, чтобы не применять имя ветки, просто потому, что в этих случаях я предпочитаю специально устанавливать специальный классификатор RC<number> для релиз-кандидатов, но это вопрос условностей/вкуса/ привычки, вы можете применить тот же подход и к этой ветке, если на Nexus не возникнет коллизий. Также обратите внимание: при использовании интеграции JIRA/Stash/Git имя ветки релиза обычно имеет вид release/v0.1.0, где символ / может вызывать проблемы в некоторых ОС (хотя это все еще можно исправить с помощью дальнейшей замены регулярных выражений, если это действительно необходимо).
• При работе на master: эй, никто не должен работать на master :) дело там просто как перепроверка, но это на самом деле не требуется

Предупреждения относительно этого подхода:

• Как поясняется в приведенном ниже обсуждении в комментариях, если соответствующий проект Maven уже использует классификаторы и, тем более, межмодульные зависимости (например, зависимости от классов области тестирования из другого модуля), то этот подход следует тщательно протестировать, поскольку он может иметь некоторые недостатки
• Публикация файлов <artifactId>.pom, содержащих классификатор ветвей, может конфликтовать с основной сборкой (т.е. переопределять ее)

Это не работает. Приводит к появлению предупреждений по всей сборке и ошибке GC при запуске из верхнего родителя.

В идеале мы хотим использовать версию, чтобы отличать ветку функций от основной ветки, потому что это обычный способ maven, а манипуляции с классификатором могут привести к всевозможным проблемам.

Поскольку maven может использовать переменные среды для свойств, и мы уже инициализируем среду сборки с помощью сценария (у нас также есть сценарии git hook, которые могут устанавливать переменные среды из имен веток), мы можем использовать env для управления версией.

<groupID>my.project</groupId>
<artifactID>database</artifactId>
<version>1.2.0${env.BRANCHMODIFIER}-SNAPSHOT</version>

Если при разработке наших скриптов установите для BRANCHMODIFIER значение ""
Если для feature/JIRA-30495 наши скрипты установите для BRANCHMODIFIER значение ".30495"

Как это работает в eclipse или Intellij? Пока нет подсказки.

Мы используем ту же технику, что и Питер Кан, изменяя версию ветки перед сборкой. У нас есть три шага в наших «Предварительных шагах»:

1. Выполнить оболочку: echo VERSION=$(echo ${GIT_BRANCH} | sed 's_^.*\/__') > env.properties
2. Внедрить переменные среды: env.properties
3. Вызвать цели Maven верхнего уровня: versions:set -DgenerateBackupPoms=false -DnewVersion=${VERSION}-SNAPSHOT

Я совершенно уверен, что это можно сделать и с двумя или даже с одним-единственным шагом, но принцип за этим будет тот же.

Причина, по которой мы не меняем версию в файлах pom.xml в ветке напрямую, действительно заключается в слиянии. С SVN это было возможно (слияние с --accept-mine-conflict. С GIT этого больше не существует, поэтому мы перестали менять версии и создали эти шаги перед сборкой.

Для Maven ge 3.5.0 попробуйте это https://maven.apache.org/maven-ci-friendly.html Это рекомендуемое решение Maven. Единственная проблема (но необычная) может заключаться в разрешении числовых версий зависимостей maven. Но это появляется только в том случае, если вы используете разные зависимости SNAPSHOT модуля, что в любом случае является плохой идеей.