rpm-maven-plugin truncates rpm version

Question

I am building three packages with rpm-maven-plugin. One parent, and two plugins that require the parent in the same version. Everything works fine, until I build it with XY-SNAPSHOT version. Then my rpm version gets truncated to XY part, but value of ${project.version} is still XY-SNAPSHOT. It results in plugins requiring XY-SNAPSHOT version of parent, whereas I have installed XY version.

I wonder if I can use "truncated" version in "requires" section or force a plugin not to truncate my versions...

this is my configuration:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>rpm-maven-plugin</artifactId>
    <version>2.0.1</version>
    <executions>
        <execution>
            <id>parent-package</id>
            <goals>
                <goal>rpm</goal>
            </goals>
            <configuration>
                <name>parent-package</name>
                <mappings>
                    (...)
                </mappings>
            </configuration>
        </execution>
        <execution>
            <id>first-plugin</id>
            <goals>
                <goal>rpm</goal>
            </goals>
            <configuration>
                <name>first-plugin</name>
                <mappings>
                    (...)
                </mappings>
                <requires>
                    <require>parent-package = ${project.version}</require>
                </requires>
            </configuration>
        </execution>
        <execution>
            <id>second-plugin</id>
            <goals>
                <goal>rpm</goal>
            </goals>
            <configuration>
                <name>second-plugin</name>
                <mappings>
                    (...)
                </mappings>
                <requires>
                    <require>parent-package = ${project.version}</require>
                </requires>
            </configuration>
        </execution>
    </executions>
</plugin>

Answer 1

The RPM specification treats a - as a special character. See this is the best I could find in Google

The version number is used in version comparisons. The RPM comparison algorithm 
is fairly complex, but can get fooled by strange version numbers. So, your best 
bet is to stick to dotted numerics, such as 1.5 or 2.3.1.1.4 or 1.0. Version 
numbers such as these will compare best from within the RPM system. For example:
    Version: 1.1.2
You cannot use a dash in the version number, as RPM uses the dash to separate 
the Name-Version-Release elements. 

So a Maven version such as 1.0-SNAPSHOT would not be a valid RPM version number.

Mojo's RPM Maven Plugin does some transformations on the version number to “help” you. Specifically it strips out the -SNAPSHOT as you have found, and if there was a -SNAPSHOT it sets the rpm release to be SNAPSHOTyyyymmddHHMMSS (note the release is use to differentiate two different builds of the same version of an RPM)

What you need to do is get some properties set to the transformed version. There are a number of ways to do this. As I suggested in a comment you could use build-helper:regex-property to transform the property. The downside of this approach is that if the RPM plugin modifies the rules that it uses for version transformation your regex may leave you out of sync.

The correct solution is to use the rpm:version goal to set the rpm.version property for you, so your configuration becomes:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>rpm-maven-plugin</artifactId>
    <version>2.0.1</version>
    <executions>
        <execution>
            <id>properties</id>
            <goals>
                <goal>version</goal>
            </goals>
        </execution>
        <execution>
            <id>parent-package</id>
            <goals>
                <goal>rpm</goal>
            </goals>
            <configuration>
                <name>parent-package</name>
                <mappings>
                    (...)
                </mappings>
            </configuration>
        </execution>
        <execution>
            <id>first-plugin</id>
            <goals>
                <goal>rpm</goal>
            </goals>
            <configuration>
                <name>first-plugin</name>
                <mappings>
                    (...)
                </mappings>
                <requires>
                    <require>parent-package = ${rpm.version}</require>
                </requires>
            </configuration>
        </execution>
        <execution>
            <id>second-plugin</id>
            <goals>
                <goal>rpm</goal>
            </goals>
            <configuration>
                <name>second-plugin</name>
                <mappings>
                    (...)
                </mappings>
                <requires>
                    <require>parent-package = ${rpm.version}</require>
                </requires>
            </configuration>
        </execution>
    </executions>
</plugin>

If you need the property to have a different name just use the versionProperty configuration parameter, but keep in mind that with multiple executions you probably want to leave it to its defaults

Answer 2

To expand a bit on @StephenConnolly's excellent answer, the maven and rpm versioning strategies have some specific differences. The differences are mostly around maven's version qualifier and rpm's build (or release) attribute.

Maven treats any version without a qualifier as being newer than a version without a qualifier. Maven also has special handling for any qualifier which ends with SNAPSHOT. RPM on the other hand requires a build number and compares on that value. Not surprisingly, rpm has no special logic for SNAPSHOT.

Since we are working in maven, we need to follow maven's rules/behavior and determine how to massage values in rpm to make that work. What this means is that we need to establish rules for massaging the rpm release value to achieve the following based on maven qualifiers:

• 1.0-alpha-1-SNAPSHOT
• 1.0-alpha-1
• 1.0-alpha-2
• 1.0-beta-1
• 1.0-SNAPSHOT
• 1.0

Additionally, we want multiple SNAPSHOT builds of rpms to be able to identify newer (by build date) and upgrade correctly.

The documentation for the release attribute describe the rules to achieve this desired behavior.

You are welcome to override this default behavior, but I would caution you to be very careful about being sure that rpm being built with identical metadata (arch, os, version, release) contain identical content.