Maven-release-plugin workflow with buildserver

Question

I am playing around with the maven-release plugin, but I have some issues with it. Especially, how the workflow is intended to be when working with a build sever.

So lets look into the configuration

This is my pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...">


    <scm>
        <url>https://bitbucket.org/our-company/our-project</url>
        <connection>scm:git:[email protected]:our-company/our-project.git</connection>
        <developerConnection>
           scm:git:[email protected]:our-company/our-project.git
        </developerConnection>
        <tag>2.1.0</tag>
    </scm>

   <properties>
        <java.version>21</java.version>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>

        <maven-release-plugin.version>3.1.1</maven-release-plugin.version>
        <conventional-commits-policy.version>1.0.7</conventional-commits-policy.version>
    </properties>


    <build>
        <plugins>

            <!-- Use the maven release plugin to release new versions.
               - please find the instructions in the readme on how the release workflow actually works.
               - https://maven.apache.org/maven-release/maven-release-plugin/index.html -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-release-plugin</artifactId>
                <version>${maven-release-plugin.version}</version>
                <dependencies>

                    <!-- Use the conventional commits version policy to propose next version numbers.
                       - See https://www.conventionalcommits.org/en/v1.0.0/ and https://maven.basjes.nl/ -->
                    <dependency>
                        <groupId>nl.basjes.maven.release</groupId>
                        <artifactId>conventional-commits-version-policy</artifactId>
                        <version>${conventional-commits-policy.version}</version>
                    </dependency>
                </dependencies>
                <configuration>

                    <tagNameFormat>@{project.version}</tagNameFormat>

                    <!-- Set the version of submodules to the same version as the overall project-->
                    <autoVersionSubmodules>true</autoVersionSubmodules>

                    <!-- Use the conventional commits version policy to propose next version numbers. -->
                    <projectVersionPolicyId>ConventionalCommitsVersionPolicy</projectVersionPolicyId>
                </configuration>
            </plugin>
        </plugins>
    </build>



</project>
  

• Differently to jgitflow, I have to merge everything to the main branch myself.
• I would assume, that I then call mvn release:prepare so that version numbers are set.

  I noticed, that this already results in tags being created, the version without the -SNAPSHOT is created and pushed and the next develop version is also created. So in regards to git, the release is finished.

• Next I'd assume that bitbucket piplines performs the release on a tag-based build configuration, executing mvn release:perform, which results in a mvn deploy

Now, what I am confused about is, that there is a file created in the release:prepare phase, that is not checked in, but required for the release:perform phase.

How is the process then meant to be?

Answer 1

The workflow of the Maven Release Plugin is rooted in the idea that the release happens locally on someone's computer.

You can also use it on a build server (essentially performing release:prepare and release:perform right after each other), and I have done that in the past, but nowadays, with advanced build systems like GitHub Actions or GitLab CI, I would opt for spelling out the steps in the build system instead of using the Maven Release Plugin.