2

This is the script on build.xml, in a non maven project, on Netbeans, every time that I "Build", it is increased by 1.

<target name="-pre-compile" description="Sets the buildversion for the current build">
<propertyfile file="${src.dir}\recursos\language.properties">
    <entry key="application.buildnumber" value="1" type="int" operation="+"/>
    <entry key="application.builddate" value="now" type="date"/>
</propertyfile>
</target>

This is resources file that I use and I want Maven write it too: languange.properties

application.title=Software title...
#build version control
application.buildnumber=334
application.builddate=2016/09/07 15\:16
application.version=1
application.icon=/icons/icon.png

I already read about mojohaus but doesn't seems to fit what I need.

I know that I have to add a Plugin, with some Executions/Goals tags, but I don't know how to tell Maven that increase that property's value by 1.

A_Di-Matteo
  • 26,902
  • 7
  • 94
  • 128
FiruzzZ
  • 661
  • 1
  • 6
  • 21
  • 1
    Have you looked in to [filtering](https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html)? That would let you copy in properties defined in the POM to the `language.properties` file, although it doesn't help you with auto-incrementing the build number. This doesn't really sound like a common Maven use case; are you an environment where this problem could be better solved on a CI server of some kind? – Suriname0 Sep 08 '16 at 17:00
  • checked and no, with filtering is not possible to do this. I don't what exactly has to do a CI server with this, just one person really build and increase the buildnumber, before release the new version, 1.334, 1.335... other contributors doesn't. – FiruzzZ Sep 09 '16 at 02:31

1 Answers1

2

Here is how I successfully implemented it:

<build>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>properties-maven-plugin</artifactId>
            <version>1.0.0</version>
            <executions>
                <execution>
                    <phase>initialize</phase>
                    <id>read-props</id>
                    <goals>
                        <goal>read-project-properties</goal>
                    </goals>
                    <configuration>
                        <files>
                            <file>src/main/resources/build.properties</file>
                        </files>
                    </configuration>
                </execution>
                <execution>
                    <phase>generate-resources</phase>
                    <id>write-props</id>
                    <goals>
                        <goal>write-project-properties</goal>
                    </goals>
                    <configuration>
                        <outputFile>src/main/resources/build.properties</outputFile>
                    </configuration>
                </execution>
            </executions>
        </plugin>
        <plugin>
            <groupId>org.codehaus.gmaven</groupId>
            <artifactId>gmaven-plugin</artifactId>
            <version>1.4</version>
            <executions>
                <execution>
                    <id>add-dynamic-properties</id>
                    <phase>initialize</phase>
                    <goals>
                        <goal>execute</goal>
                    </goals>
                    <configuration>
                        <source>
                                project.properties.buildnumber = (project.properties.buildnumber.toInteger() + 1).toString();
                        </source>
                    </configuration>
                </execution>
            </executions>
        </plugin>

        <!-- debug print out, to be removed afterwards -->
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-antrun-plugin</artifactId>
            <version>1.5</version>
            <executions>
                <execution>
                    <phase>compile</phase>
                    <goals>
                        <goal>run</goal>
                    </goals>
                    <configuration>
                        <target>
                            <echo message="${buildnumber}" />
                        </target>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

What we are actually doing:

  • We are using the properties-maven-plugin to read a file (via its read-projet-properties goal) from a file, src/main/resources/build.properties in the initialize phase, hence really early in the default build cycle
  • Now, the buildnumber property has been pulled from the file and part of our build. During the same phase, we use the gmave-plugin to increment its value via a small script.
  • Then during the generate-resources phase (as an example) we write the new value of buildnumber (override) to the same file, for the next future iteration. This step is fundamental, since we need to store the state somewhere and it should be under version control, that is, part of the project. The src/main/resources is probably not the best choice since it will be packaged with the application (you can always skip it), so you can store it on some other file (but still it should be part of the versioned project).
  • Then, as a debug/proof, the antrun will print the current buildnumber value.

To make it work, the initial value of the buildnumber property in the build.properties file should be set a 0 (the property must exist upfront). However this file would also risk to be continuously in conflict being under version control, that's why the whole behaviour should be wrapped into a maven profile and used only in certain cases (e.g. the team leader during a release). This constraint would actually lead to a more standard approach: let a CI server handle the whole mechanism, not maven.

Side note: unfortunately, the properties-maven-plugin doesn't provide much configuration, it will always read and write all the build properties, which is harmless in most of the case although not optimal. Better would be to have an include/exclude mechanism to filter and only read/write the buildnumber property.

A_Di-Matteo
  • 26,902
  • 7
  • 94
  • 128
  • I don't understand where is pointing this: `project.properties.buildnumber = project.properties.buildnumber.toInteger() + 1).toString();` What is project? a variable? like ${project.basedir}? – FiruzzZ Sep 23 '16 at 14:19
  • it's the groovy way to get to Maven elements, sugar. Basically, via `project` (the Maven `project` element), you get to access the `properties` (that is, the element, but also the runtime object in the Maven model of the build) and you increment it. You can only use this notation in this plugin, not anywhere you would like in the `pom.xml` – A_Di-Matteo Sep 23 '16 at 14:32
  • This is almost what I wanted. The problem is (as you said it) that rewrite the entire .properties files, and in my case I use this for i18n too with the suffix _en_US, _es_AR etc.. anyway.. Thanks so much – FiruzzZ Sep 23 '16 at 16:16