maven-buildnumber-plugin svn revision available only when not using format

Question

While using the maven-buildnumber-plugin 1.0 beta 4, it seems that I can get the svn revision unless I use a <format> tag within the configuration. Once I use <format> and <item>buildnumber</item> tag, I get an auto-incrementing number, but it no longer corresponds to svn revision and I don't know how to get it back. Is there a way to use the svn revision number within the <format>? The documentation isn't very clear.

Dowsabel

are you setting a developer scm in your pom? – Boneset

@Boneset I don't think the buildnumber plugin uses that. Last time I used it (about a year ago), it just started an svn commit process, so the SVN info in the file system is what's used. – Hornet

But yes, there's an SCM set and it works except when I specify format and items. i wasn't clear because SO ate my xml. Fixed it. – Dowsabel

Answer 1

The buildnumber-maven-plugin is pretty darn quirky, which is probably why it's still a beta. The format is only for those items you wish to apply a Java message format to and in most cases, it only useful with timestamps and literal strings. If you don't need a timestamp don't use the format option when getting the Subversion revision number. If you use the format, then like you indicated, it'll give you a build number that always increments by one rather than the SCM version number.

If you do need the timestamp or have other items your deriving from the buildnumber plugin as well as the Subversion revision, do each one as a separate executions. Here's an example of how to get the Subverison revision number and the build timestamp using two separate executions of the plugin:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>buildnumber-maven-plugin</artifactId>
    <version>1.0-beta-4</version>
    <executions>
        <execution>
            <id>generate-buildnumber</id>
                <phase>validate</phase>
            <goals>
                <goal>create</goal>
            </goals>
            <configuration>
                <useLastCommittedRevision>true</useLastCommittedRevision>
                <buildNumberPropertyName>buildRevision</buildNumberPropertyName>
            </configuration>
        </execution>
        <execution>
            <id>generate-timestamp</id>
            <phase>validate</phase>
            <goals>
                <goal>create</goal>
            </goals>
            <configuration>
                <format>{0,date,yyyy-MM-dd HH:mm:ss}</format>
                <items>
                    <item>timestamp</item>
                </items>
                <buildNumberPropertyName>buildDateTime</buildNumberPropertyName>
            </configuration>
        </execution>
    </executions>
</plugin>

The key to making this work is using the buildNumberPropertyName element. Checkout the plugin's Usage page for more information about the usefulness of the Java message format is for.

Ancy

Clever. I can see this being used to get scmBranch as well. – Shrewd

Answer 2

By the looks of it no. If you use the format configuration then you are bound to using one of the default items.

From here:

Specify a message as specified by java.text.MessageFormat. This triggers "items" configuration to be read

And then from here:

Specify the corresponding items for the format message, as specified by java.text.MessageFormat. Special item values are "timestamp" and "buildNumber/d*".

Also if you look at the code for the mojo here a couple things support this:

if ( format != null )
{
    if ( items == null )
    {
        throw new MojoExecutionException(
             " if you set a format, you must provide at least one item, "
             + "please check documentation " );
    }

And:

else
{
    // Check if the plugin has already run.
    revision = project.getProperties().getProperty(
        this.buildNumberPropertyName );
    if ( this.getRevisionOnlyOnce && revision != null)
    {
        getLog().debug( "Revision available from previous execution" );
        return;
    }

By the sounds of it you are asking for a new feature (not a bad idea by the way). I would submit it as such here.

Minx

thanks for going so in-depth on it, I expected someone to tell me I was just doing something wrong – Dowsabel

You bet. Sometimes when I ask a question a: "no you can't do that" doesn't suffice :) – Minx

Answer 3

I did run into the same problem and for a few moments I thought the solution suggested by @Jean-Rémy Revy works..but it didn't for some reason.

It turns out that in buildnumber-maven-plugin-1.2 they have added support for a special property called scmVersion. As of now v1.2 is not available in the maven repository though the plugin's website suggests it is GA. So you will need to checkout the source (http://svn.codehaus.org/mojo/tags/buildnumber-maven-plugin-1.2/ )and build it ( $ mvn install ). This will also install the plugin in your local repository.

After this just do this:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>buildnumber-maven-plugin</artifactId>
    <version>1.2</version>
    <executions>
        <execution>
                <phase>validate</phase>
            <goals>
                <goal>create</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <format>{0,date,yyyy-MM-dd HH:mm:ss}.{1}</format>
            <items>
                <item>timestamp</item>
                <item>scmVersion</item>
            </items>
        </configuration>

</plugin>

Rattlebrained

Bummer that it doesn't seem to support scmBranch as a special item. – Shrewd

Answer 4

There is a compelling reason why that has been done by the plugin developer. A recommended way to get the project's build timestamp is as follows:

<project>
  <properties>
    <maven.build.timestamp.format>yyyy-MM-dd HH:mm:ss</maven.build.timestamp.format>
    <buildDateTime>${maven.build.timestamp}</buildDateTime>    
  </properties>
</project>

So all you need is to get a revision number which can be done quite well with a single invocation of the buildnumber-maven-plugin according to its documentation.

P.S. Having one execution instead of two (as was offered) saves near one second each time the plugin is invoked ;)

Altruist