${revision} not being updated

[fmodesto]

This is a sample pom to illustrate the issue
`

4.0.0

<groupId>org.example</groupId>
<artifactId>test-versions</artifactId>
<version>${revision}</version>

<properties>
    <maven.compiler.source>17</maven.compiler.source>
    <maven.compiler.target>17</maven.compiler.target>
    <revision>1.3</revision>
</properties>

<build>
    <pluginManagement>
        <plugins>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>versions-maven-plugin</artifactId>
                <version>2.14.1</version>
            </plugin>
        </plugins>
    </pluginManagement>
</build>

`

mvn versions:set -DnewVersion=2.0

With plugin 2.13.0 it resolves all ${revision} to the new version.
With plugin 2.14.0 and 2.14.1 it does nothing.

[jarmoniuk]

Regression after #799

[jarmoniuk]

Too bad we're after this hotfix release.

[slawekjaranowski]

Why do you use version:set at all when you use ci-friendly properties?

Do you also need a task to change pinned version to ${revision} like:

mvn versions:set -DnewVersion=${revision}

[deckrider]

We use ${revision}-SNAPSHOT but at official non-SNAPSHOT build time, use versions:set -DnewVersion=1.2.3 so that our version is momentarily hard coded, in this example to 1.2.3.

Thus we also have this problem. The workaround seems to be adding -DoldVersion='*'

[lavoiesl]

The workaround seems to be adding -DoldVersion='*'

This workaround also worked for me, thanks 🙏🏼

[hackmann]

Why do you use version:set at all when you use ci-friendly properties?

Do you also need a task to change pinned version to ${revision} like:

mvn versions:set -DnewVersion=${revision}

I'm looking into switch from normal versions to these CI friendly versions. I can use shell scripting to add the revision property, mvn versions:set-property does not create a property if it does not exist already. But was hoping to use mvn versions:set to set the version for main pom file and all child modules

[CharlieReitzel]

With 2.15.0, when I run mvn versions:set -DnewVersion=1.2.3 -Dmaven.main.skip -DskipTests=true -DskipUiRebuild=true -Dmaven.install.skip, the parent and the parent reference in all child projects are overwritten from <version>${revision}</version> to <version>1.2.3</version> and the revision property is ignored/unchanged.

Adding -DoldVersion='*' made no difference.

What am I missing?

Fwiw, I'm using a multi-module project with a CI pipeline that is forcing the versions:set on every merge to main. I have no control over the pipeline and the team that does is stretched thin. So if I can get a project that uses $revision to work with versions:set, it'll be a big help.

[deckrider]

@CharlieReitzel see this scenario: #855 (comment)

[jarmoniuk]

I don't think that the set goal will update a property value.

Before version 2.13.0, it did not interpolate properties at all. In versions 2.14.0 and 2.15.0 it made an incomplete attempt at doing it, but I'm now reverting that behaviour.

[CharlieReitzel]

Thanks for the quick responses on a closed ticket.

@deckrider said:

see this scenario: #855 (comment)

That's where I got the idea to try -DoldVersion='*'.

@ajarmoniuk So, if I understand it right. If you use version:set -DnewVersion=1.2.3 on a project using <version>${revision}></version>, you are asking the plugin to drop use of the revision property in favor of a fixed version. Is that the intent? Fwiw, if so, it is working :--).

Should I submit a feature request to support updating the version for projects that use the $revision property by simply updating the revision property value on the parent POM and leaving everything else alone?

[jarmoniuk]

Yes, of course you can request a new feature.

By the way, what are you trying to achieve by trying to use set on CI-friendly versions?

Edit: Unless your ${revision} properly is also defined in your POM, then you should have rather used the set-property goal.

[CharlieReitzel]

In our work environment, all projects use shared CI/CD pipeline code that forces a version update with every merge to main by calling mvn versions:set -DnewVersion=1.n.0, i.e. takes your highest level version number as is, increments your 2nd level version level by 1 and sets the lowest level version to zero (0). It figures out the version number on its own.

Because I'm using a multi-module project, I'm using $revision to keep parents and children in sync by:

1. Using $revision to refer to the parent version from the child modules
2. Avoiding specifying a version in the child modules.

Fwiw, I don't see any logical conflict or disconnect between using CI-friendly ($revision) and versions:set. But I'm probably missing something. :--)

[jarmoniuk]

So, did you try using set-property instead?

[CharlieReitzel]

I can play with it, manually. But, as I said, my project has to work with a standard CI pipeline that forces mvn versions:set -DnewVersion=N.x.0 with every merge to main.

I have no problem with that scheme, either. To my mind the "least surprise" implementation of versions:set on a project that uses $revision is to simply update the property value in the top level pom.xml.

[jarmoniuk]

Please do file a feature request.

The set goal you described is supposed to update the version of the project with which it was invoked across the agregator, i.e. also update it where it's used as parent or dependency. So I understand the intention of the pipeline maintainer and the invocation of set should leave the project in a consistent state.

If this does not occur then it's a bug, and might be caused by #799. Please notify the pipeline maintainer of that fact. However, the set goal in the pipeline would replace your property with a direct value, which is not what you want.

Regarding one remark – by "CI-friendly versions" I understand versions where the property is defined outside of the reactor, typically in the pipeline, e.g. by using the -Drevision switch. So it would not make sense to define a property in the project, which is then redefined in the pipeline anyway, hence my surprise.

So, unfortunately what you're looking for is not currently available with the set goal.