maven release plugin with parameterized version

Question

is it possible to use the maven release plugin with a multi-module project, where some of the inter-module dependencies are specified using a parameter from the parent pom?

When I try to call release:prepare i get the following error:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.1:prepare (default-cli) on project forest-parent: The version could not be updated: ${some.version} -> [Help 1]

Here is my plugin definition:

<plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-release-plugin</artifactId>
            <version>2.1</version>
            <configuration>
                <goals>deploy</goals>
                <tagBase>https://svn.domain.com/svn/project/tags</tagBase>
                <autoVersionSubmodules>true</autoVersionSubmodules>
                <tagNameFormat>@{project.version}</tagNameFormat>
            </configuration>
        </plugin>

Thanks in advance!

You can answer your own question with your solution and mark it as correct - that way the question will not be "unanswered" anymore plus people get the chance to upvote your answer as well :-) — Jan, Mar 16 '12 at 10:23

score 4 · Accepted Answer · answered Mar 19 '12 at 07:37

4

The plugin currently doesn't support parameterized versions from parent (tried v2.2.2 as well). The solution was to use {project.version}.

answered Mar 19 '12 at 07:37

kpentchev

3,040
2
24
41

1

Oddly, indirect properties do not work. In other words, if I defined ${project.version} and then try to use ${some.version} on the itself, it doesn't work. But using ${project.version} directly in the dependency does. – Ben May 08 '12 at 20:30
2

@Ben adding "project." prefix to properties seems to solve the problem – ichaki5748 Jun 05 '14 at 19:10
3

@Isaak This only partially solves the problem, because the properties in the `` tags will be substituted with the value of the version, making the properties useless... – Dormouse Aug 21 '15 at 11:06

Rhubarb · Answer 2 · 2020-07-01T09:37:27.127

TL;DR: Accepted answer does not help; Known defect in maven-release-plugin; New CI-Friendly versions in maven 3.5 help somewhat (but don't really solve the OPs issue)

Long version:

The accepted answer doesn't work. I experimented and found the results commented by @Dormouse. Adding this answer for more clarification:

Prefixing the variable name with "project." gets maven release:prepare past the original error, but it will update the version of the custom-versioned module to match all the others

So, as @Dormouse states, the property is useless because after the first maven release call it will no longer refer to the correct version of the module.

For example - some excerpts from a demonstration:

parent pom.xml:

<version>1.0-SNAPSHOT</version>
<properties>
    <!-- note the custom property starts with "project" to pass release:prepare -->
    <project.version.custom>1.2-SNAPSHOT</project.version.custom>
</properties>
<modules>
    <module>custom-versioned-module</module>
    <module>dependent-module</module>
</modules

custom-versioned-module/pom.xml:

<parent>
    <version>1.0-SNAPSHOT</version>
</parent>
<artifactId>custom-versioned-module</artifactId>
<!-- this module has 1.2-SNAPSHOT instead of 1.0-SNAPSHOT like the rest -->
<version>1.2-SNAPSHOT</version>

dependent-module/pom.xml

<parent>
    <version>1.0-SNAPSHOT</version>
</parent>
<artifactId>dependent-module</artifactId>
<dependencies>
    <dependency>
        <artifactId>custom-versioned-module</artifactId>
        <!-- experiment with variable version -->
        <version>${project.version.custom}</version>
    </dependency>
 </dependencies>

Now try mvn release:prepare -DdryRun=true and examine the files created. (You can see what the release:perform would do by looking at pom.xml.next - this is used to replace pom.xml if you do not use -DdryRun)

You will see that the version property is left intact, as is the dependency (we wouldn't expect the maven-release-plugin to mess with those), but the actual version of custom-version-module is changed!

custom-versioned-module/pom.xml.next:

<parent>
    <version>1.1-SNAPSHOT</version>
</parent>
<artifactId>custom-versioned-module</artifactId>
<version>1.1-SNAPSHOT</version>

The parent version is increased from 1.0 to 1.1, but the module version is decreased from 1.2 to 1.1 (it's simply made the same, not specifically decremented)

Meanwhile the property itself remains at 1.2 so if you actually release, the next build will fail.

Note that this is logged as maven defect here: https://issues.apache.org/jira/browse/MRELEASE-782

And it is somewhat mitigated by the CI-Friendly versioning in 3.5:

https://maven.apache.org/maven-ci-friendly.html

maven release plugin with parameterized version

2 Answers2

Linked