4

Due to the way my build system is designed (RTC Build Engine), I would like to provide maven with property values via a properties file, instead of specifying -Dkey=value for every property.

I found a couple of questions on S.O. (How to set build properties from a file in Maven POM? and How to read an external properties file in Maven) that relate precisely to this question, but they are relatively old, and both require custom plugins to work (in alpha state).

I realize that passing parameters to Maven like this is probably not the best solution, but the other option is specifying everything on the command line via -D settings which is not ideal either.

Furthermore, given that this properties file is only really used by the build engine (and not by the individual developer), I don't truly believe it belongs in the pom. But I cannot find any other mechanism that would allow me to specify a plugin to use - settings.xml does not permit specifying plugins.

Is my only choice in this case to use a plugin and specify it in the project pom?

Community
  • 1
  • 1
Eric B.
  • 23,425
  • 50
  • 169
  • 316
  • Can you give real examples of what kind of properties you would like to provide? – khmarbaise Jan 16 '15 at 15:25
  • @khmarbaise : ex: -Dcore-version=1234 -Dlib-version=1234 -Dbuild-version=9999, -Dbuild-date=20150101, etc. – Eric B. Jan 16 '15 at 15:41
  • Why do you like to define lib-version? Does not make sense? Cause they are defined in the pom. What i can understand is using things like build-version...Build-Date (this could be handled in different ways). – khmarbaise Jan 17 '15 at 11:20
  • @khmarbaise I don't like to define these values parameter style, but unfortunately, I have no choice. I am migrating an existing production build system from one source control/build system to a different one, and their current build uses scripts and manually defined vars. It is an iterative process, and the long term goal is to remove these vars altogether, but as a first step, it has to be done this way. – Eric B. Jan 18 '15 at 02:15

2 Answers2

7

in the pom you can place...

<properties>
    <core-version>1234</core-version>
    <lib-version>1234</lib-version>
    <build-version>9999</lib-version>
    <build-date>20150101</build-date>
</properties>

with all the properties you require.

Or you can use...

<build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>properties-maven-plugin</artifactId>
        <version>1.0-alpha-2</version>
        <executions>
          <execution>
            <phase>initialize</phase>
            <goals>
              <goal>read-project-properties</goal>
            </goals>
            <configuration>
              <files>
                <file>dev.properties</file>
              </files>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

and the file dev.properties will contain the properties

core-version=1234
lib-version=1234
build-version=9999
build-date=20150101
...

Or... you can inject the properties using a settings.xml file as shown here

You may also find the Maven build number plugin useful... here

Joe
  • 165
  • 2
  • I had found that plugin already, but have concerns about the fact that it hasn't been touched since 2009. So I was looking to see if there was a "better" way of doing this. I am surprised that in 5 years, no one has come up with a different, more accepted way than using a plugin that is still in "alpha" state. – Eric B. Jan 16 '15 at 15:47
  • What about deliviering patches for the plugin and improve it? It's open source...? – khmarbaise Jan 17 '15 at 11:17
  • I basically ended up with this solution. Not my preferred one, but functional for the time being. Thanks. – Eric B. Jan 18 '15 at 02:17
  • 1
    Ack. Just discovered that I cannot specify version numbers using properties set via a plugin as maven does not view the pom as being valid if there are undefined version #s. Hence it does not even kick off its lifecycle. I even tried putting the plugin in the validate phase, but doesn't seem to work. – Eric B. Jan 21 '15 at 17:23
1

The best in such cases is to upgrade to at least Maven 3.2.1 which supports defining such properties on the command line like the following:

mvn -Drevision=1234 -Dchangelist=WhatEver -Dsha1=XXXX clean package

But you can only use the above names.

Excerpt from release notes:

A simple change to prevent Maven from emitting warnings about versions with property expressions. Allowed property expressions in versions include ${revision}, ${changelist}, and ${sha1}. These properties can be set externally, but eventually a mechanism will be created in Maven where these properties can be injected in a standard way. For example you may want to glean the current Git revision and inject that value into ${sha1}. This is by no means a complete solution for continuous delivery but is a step in the right direction.

khmarbaise
  • 92,914
  • 28
  • 189
  • 235