Maven release: next development version in batch m

问题:

I have configured a Jenkins job to release my maven project automatically. This is done by using the following: mvn --batch-mode clean release:prepare release:perform In batch mode the release version and the development version will be determined automatically. This is exactly what I want.

The problem is that I want to increase the 2nd number of the version instead of the 3rd one. So when I release version 1.2.0, the next development version must be 1.3.0-SNAPSHOT. Not 1.2.1-SNAPSHOT. Adding a commandline parameter is not an option, because that forces me to constantly edit the build job.

Any suggestions on how to change the algorithm used to determine the next development version?

回答1:

I know this is a kinda old post but I didn't find an answer I really liked anywhere online and I was able to come up with something that might work well for others...

I wanted to increment the minorVersion as the OP states, and I was able to do so by using a combination of the build helper plugin (to parse the version) and the release plugin, in my project POM. Note the "initialize" phase referenced in the POM and the maven run property...

Here's the excerpt from the POM, we use the build helper plugin to parse the version which we can reference in the release plugin...

<plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>build-helper-maven-plugin</artifactId>
                <version>${maven.build.helper.plugin.version}</version>
                <executions>
                    <execution>
                        <id>parse-versions-for-release</id>
                        <phase>initialize</phase>
                        <goals>
                            <goal>parse-version</goal>
                        </goals>
                        <configuration>
                            <propertyPrefix>parsedVersion</propertyPrefix>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-release-plugin</artifactId>
                <version>${maven.release.plugin.version}</version>
                <configuration>
                    <autoVersionSubmodules>true</autoVersionSubmodules>
                    <tagNameFormat>@{project.artifactId}-@{project.version}</tagNameFormat>
                    <useReleaseProfile>false</useReleaseProfile>
                    <developmentVersion>${parsedVersion.majorVersion}.${parsedVersion.nextMinorVersion}.0-SNAPSHOT</developmentVersion>
                </configuration>
            </plugin>

Now we can just run a pretty normal release, but adding in the "initialize" phase to trigger the version parsing (and ensure it occurs prior to looking for the parsed versions)...

mvn initialize release:clean release:prepare release:perform

回答2:

You could use a commandline parameter without editing the job if you use a parameterized build in Jenkins. Check the "this build is parameterized" option in the job configuration page.

This won't let Jenkins perform releases entirely on its own (which is good; we don't want the robots to take our jobs!) -- when you manually kick off a build from within Jenkins, you'll be able to set any parameters you've configured.

回答3:

As suggested it Khmarbaise, I also think that there is no solution to your problem.

Is there any rule, that can automatically tell you if you must change the second or the third number ? Indeed, I don't think so. Saying that, you can't ask Maven / Jenkins to choose it for you, one time major version digit, the other minor version digit.

You must change it via a parameter, or let user configure it via the Jenkins M2 Release plugin, as suggested by willome. It can only be a manual action.

回答4:

You can use a custom groovy script to automatically provide maven-release-plugin with the releaseVersion and developmentVersion. Then the maven command would look somwthing like:

mvn clean release:clean release:prepare release:perform -DreleaseVersion=${releaseVersion} -DdevelopmentVersion=${developmentVersion}

Follow the steps in this answer and change the part of the groovy script to suite your use-cases (for example this part):

def newFixVersion = 0;
if (hasSnapshotPart) {  
    newMinorRelVersion = minorVersion;  
    newMinorDevVersion = minorVersion + 1;  
} else {  
    //TODO: either throw an exception here or change the newMinorRelVersion newMinorDevVersion appropriately to suite your use-cases: 
        //throw new IllegalArgumentException("The pom at location " + POM_LOCATION + " contains the version " + projectVersion + " which is not a snapshot version (missing " + SNAPSHOT_PART + "). This is a released version and nothing should happen to it!");  
}  

回答5:

I had the same problem and I wanted to resolve it without running more than one command or by inserting the version manually.

Here is my solution for y (or minor) increment:

I run a Groovy script in initialize phase. This script creates release.properties. Add this to your project/build/plugins section in your pom.xml:

        <plugin>
            <groupId>org.codehaus.gmavenplus</groupId>
            <artifactId>gmavenplus-plugin</artifactId>
            <version>1.5</version>
            <dependencies>
                <dependency>
                    <groupId>org.codehaus.groovy</groupId>
                    <artifactId>groovy-all</artifactId>
                    <version>2.4.6</version>
                </dependency>
            </dependencies>
            <executions>
                <!-- Force maven-release-plugin to increase MINOR, not PATCH, and create tag as vX.Y.Z -->
                <execution>
                    <id>release-parameters</id>
                    <phase>initialize</phase>
                    <goals>
                        <goal>execute</goal>
                    </goals>
                    <configuration>
                        <scripts>
                            <script>
                                <![CDATA[
                                    final String SNAPSHOT = '-SNAPSHOT'

                                    Properties releaseProps = new Properties()
                                    File releasePropsFile = new File('release.properties')
                                    String releaseVersion = '${project.version}'.replace('-SNAPSHOT', '')
                                    String[] vNumbers = releaseVersion.split('\\.')
                                    String snapshotVersion = vNumbers[0] + '.' + (Integer.parseInt(vNumbers[1]) + 1) + '.' + '0' + SNAPSHOT

                                    releaseProps.setProperty('scm.tag', 'v' + releaseVersion)
                                    releaseProps.setProperty('project.rel.${project.groupId}:${project.artifactId}', releaseVersion)
                                    releaseProps.setProperty('project.dev.${project.groupId}:${project.artifactId}', snapshotVersion)
                                    releaseProps.store(releasePropsFile.newWriter(), null)
                                ]]>
                            </script>
                        </scripts>
                    </configuration>
                </execution>
            </executions>
        </plugin>

This script changes also the tag name for vX.Y.Z in your SCM. The initialize phase is not executed in the release:prepare phase. To resolve this issue, you can run a "mvn install" before a release, or change your release command to:

mvn --batch-mode initialize clean release:prepare release:perform

About release.properties: https://maven.apache.org/maven-release/maven-release-plugin/examples/non-interactive-release.html