maven - 使用功能分支时避免 Maven 存储库版本冲突

Question

问题:如何处理 Maven 多项目构建的功能分支？

Jenkins 构建和部署这些分支，以将开发人员的构建开销降至最低，但开发和功能分支无法构建相同的 Maven 版本，否则我们将面临 Artifact 和源代码之间不匹配的风险。

我们有一个脚本可以更改子 pom 中的父版本和根 pom 中的版本。虽然这在 Maven 空间中隔离了分支，但在合并时会导致额外的工作。

我认为 Nexus Pro 登台功能可能会帮助我们避免这一要求，并使每个功能分支使用一个特定的存储库，我们在分支删除/合并后可以轻松删除该存储库。

再说一遍:如何处理多分支和maven的问题？

Answer 1

以下方法怎么样:

• 使用 buildnumber-maven-plugin 从 git 获取信息并填充特定的 Maven 属性(我们对 scmBranch 属性特别感兴趣(即当前的 git 分支)
• 使用 build-helper-maven-plugin 检查我们是否处于功能分支中(通过 regex ，不包括众所周知的分支，如 master 、 develop 等)并填充(或不填充)新的 Maven 属性，例如 branch.classifier
• 使用 maven-jar-plugin 根据上一步设置的内容，在生成的 Artifact 上设置分类器，即使用新的 branch.classifier property:如果为空，则不会应用任何分类器(默认行为，例如应用于 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 上不会发生冲突:分类 Artifact 将具有不同的 Maven coordinates ，即GAV(groupId，artifactId，version)变成唯一的GAVC(+classifier)
• 这实际上是 classifier 的一个有意义的用法。 Artifact 的属性:

  The classifier allows to distinguish artifacts that were built from the same POM but differ in their content.

• 生成的 Artifact 将根据其源分支在 Nexus 中动态变化，因此具有隐式可追溯性:无需开发人员干预(不易出错，隐式约定)，无需 CI 作业干预(更容易维护)，完全透明
• 使用分类器，可以更轻松地将分支生成的 Artifact 用作 Maven 依赖项(例如，在库项目的情况下):我想使用当前正在分支 xxx 上开发的依赖项

示例
因此，您将生成以下 Artifact :

• 在处理 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包含分支分类器的文件可能会与主线构建发生冲突(即覆盖它)