Reading Properties file from POM file in Maven

Question

Why is this NOT working ? How to pick the version numbers from the properties file.

Reading properties in pom.xml

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

In dev.properties

org.aspectj.aspectjrt.version=1.6.11

Dependency in pom.xml

        <dependency>
            <groupId>org.aspectj</groupId>
            <artifactId>aspectjrt</artifactId>
            <version>${org.aspectj.aspectjrt.version}</version>
        </dependency>

Error : dependency must be a valid version

Impala

why not specify the version? om the pom file? – Quimby

Answer 1

When you start up Maven from the command line, it goes through a number of stages. Here is a pseudo description of these stages, I am intentionally simplifying the exact sequencing (with the risk of saying things that are slightly incorrect/out-of-order) so that you can see why what you are trying to do cannot work.

1. First it parses your command line, any properties defined on the command line using the -Dname=value are injected into the MavenSession

2. The reactor defining command line options are checked to decide what the list of projects to build (also known as the reactor) should be. -N means build only the root pom.xml, -pl allows specifying a list of modules to build, -am and -amd allows adding upstream or downstream, respectively, modules from those specified by -pl. Maven has not parsed any pom.xml files at this point in time.

3. The -P profile activation rules are parsed to see what profiles to activate.

4. Now Maven has enough knowledge to start parsing the pom.xml files. It starts by loading and parsing the root pom.xml, i.e. the one in the current directory (or if you specified an alternative pom.xml with -f then that one). This initial parse is just concentrating on figuring out the list of projects to build. Profile activation is only considered in so much as it may affect the list of <modules> that are available. The Group Id, Artifact Id, Version and Packaging coordinates in the pom.xml cannot contain properties because the parsing of the properties in the pom.xml has not taken place at this point in time. (The observant reader will also see that this also explains why you cannot activate profiles based on properties within the pom.xml, as only system properties have been parsed at this stage)

5. Once the set of projects has been validated, Maven now does some more parsing of those pom.xml files to construct the list of build extensions (if any) and the list of plugins. At this stage the parsing requires evaluation of the <properties> in each project, so this is when these get evaluated and "injected" into the effective model. Thus you can use system properties and pom properties to define the coordinates and additional dependencies within (xpath) /project/build/extensions, /project/build/pluginManagement/plugins/plugin, /project/build/pluginManagement/plugins/plugin/dependencies, /project/build/plugins/plugin and /project/build/plugins/plugin/dependencies.

6. Now Maven starts parsing the list of goals and phases specified on the command line. Partially specified goals are evaluated for a match against the list of plugins. The match must be unique for all the projects that the plugin goal will be executed against (i.e. if it is an aggregator goal, the match is only required at the root, but for all other "normal" goals, the plugin short name must be the same plugin for all projects). Lifecycle phases must be from one of the default lifecycles, or from a lifecycle defined in a build extension.

7. From the parsed list of goals and phases, Maven constructs the build plan, i.e. what it is going to do on which projects and in what order. In order to do this Maven must parse the list of project dependencies defined in the reactor projects pom.xml files. This is because a dependency may be produced by another project within the reactor, thereby forcing a sequencing of project execution. Thus you can use system properties and pom properties to define the coordinates and additional dependencies within (xpath) /project/dependencyManagement/dependencies/dependency and /project/dependencies/dependency but note that at this point in time, no plugins have been executed.

8. Now that Maven has the build plan, it starts following that plan in the order that it constructed. If the first goal/phase on the CLI was a goal, then that goal will be invoked. If the first goal/phase was a phase from the default build lifecycle, then Maven will start with the initialize phase and execute all the plugins bound to that phase... continuing in a similar manner along the list of phases and then the list of projects. Note also that the initialize phase is only executed as part of the default build lifecycle. It is not executed on the default clean or default site lifecycles, and it is not executed on any custom lifecycles. (The observant reader will conclude that this highlights another problem with the technique that the question is attempting). Note: keep in mind that aggregator goals form a "break" in the reactor, so if you ask Maven to run clean package foo:bar site where foo:bar is an aggregator mojo goal, then clean package will be run against all the projects in the reactor, then foo:bar will be run against the root, then site will be run against all the projects in the reactor. In other words, the build plan will take the longest continuous run of non-aggregator goals & phases, split by longest continuous runs of aggregator goals.

9. Before it calls each mojo (i.e. goal bound to a phase or directly specified from the command line) Maven evaluates the pom.xml for the effective <configuration> of that mojo. At this point Maven has available the system properties, the properties specified in the pom and any properties injected into the MavenSession by previously executed mojos. Thus the <configuration> can reference any of those properties...

   Aside

   Now there is a caveat... if you say set (xpath) /project/build/directory to ${some-property-i-will-set-via-a-mojo} and then reference that from your <configuration>, well the sad news is that (xpath) /project/build/directory will have been evaluated into the effective pom.xml before any plugin execution, so ${project.build.directory} will have been given the literal value ${some-property-i-will-set-via-a-mojo} and that is of type java.io.File in the MavenProject so what you will actually have had happen is new File(project.getBaseDir(),"${some-property-i-will-set-via-a-mojo}"). If the <configuration> field you are injecting into is of type File, there will be no type conversion required, and hence the value will be injected straight in, and no property substitution will have taken place.

   There are other edge cases, like the one outlined above, but in general property substitution will work with "mojo injected" properties (such as those provided by Mojo's Properties Maven Plugin) within the <configuration> sections. It will not work outside of those sections.

So here is Stephen's quick rule of thumb for the different property types:

System Properties

These work everywhere... but are extremely dangerous in /project/(parent/)?/(groupId|artifactId|version|packaging) as you have no control what so ever on what system properties will be defined when the project is pulled in as a transitive dependency. Use of ${...} expansion within /project/(parent/)?/(groupId|artifactId|version|packaging) should be considered as equivalent to driving a car at 200kph with a 30cm (12 inch) metal spike protruding from the steering wheel in place of an airbag... oh and no seat belt... and you've just had 10 units of Alcohol and two lines of cocaine.

pom.xml properties (and settings.xml properties)

These work in most places, but are never available within /project/(parent/)?/(groupId|artifactId|version|packaging) (as they have not been parsed when those fields are being evaluated) and are not available for consideration of the active profiles (again as they have not been parsed when profile activation is being evaluated)

Mojo injected properties

These work within <configuration> sections and may (due to the recursive interpolation of injected Mojo String parameters) work when used indirectly, but given the uncertainty involved, the recommendation is to restrict their use to the <configuration> section of plugins and reports only.

One final thing

Think about what happens when your project is listed as a dependency. If you had specified its dependencies by using a mojo to pull those from a .properties file on disk, Maven has no way to replicate that when your dependency has been pulled from the Maven repository. So Maven would be unable to determine the dependencies. Thus it could never work.

What you could do, is use an external system (e.g. ANT) to generate the pom.xml from a template with the versions replaced into that file. And then use the instantiated template to build.

Johnsten

i disagree, i am using buildnumber-maven-plugin in validate phase and its generated buildnumber in version as ${buildNumber} and it is working and generate jar file with buildnumber in file name. – Rowell

You will find that the jar name cannot be preserved when pushed to the local/remote repository. The jar name in the target directory can be affected as that is evaluated during the package phase... But it only holds for things evaluated after the lifecycle has started up. The GAV coordinates are evaluated before the lifecycle fires up. In multi-modules build you will see that anything you may think you have working with property substitution into the GAV is actually broken – Johnsten

Answer 2

Just throwing out an idea - Create a parser for whatever properties format you want (.properties, .yml, etc)that spits out a .mvn/maven.config file with

-DpluginXX.version=123
-DpluginYY.version=456
etc

According to Stephen's both enlightening and disappointing answer, this is stage 1 evaluation.

Integrate in .mvnw ? This would allow standard ./mvnw <args> semantics to be basically seamless.

"It's not ugly if you can encapsulate it" - said most engineers at some point in their careers.

Valeriavalerian

Answer 3

There is a way to basically do what you want via the infamous maven versions plugin. Here's how:

1. for each variable you want to use, eg ${org.aspectj.aspectjrt.version} you must also define it in the properties section of your same document (just use dummy values for now)

<properties> 
 
 <org.aspectj.aspectjrt.version>0.0.0</org.aspectj.aspectjrt.version>
 <some.other.prop>abc</some.other.prop>
</properties>

2. define the real values in a properties file, eg put this in app.properties:

org.aspectj.aspectjrt.version=1.0.0
some.other.prop=def

3. now use the versions command to propagate your all your property values into the pom file like this:

mvn versions:set-property -DpropertiesVersionsFile=app.properties -DgenerateBackupPoms=false

Your pom.xml should now have updated values matching those found in app.properties.

4. In case you have several pom.xml files you'd like to update at once, you can define them as submodules in an aggregate pom.xml, and then apply the above command to the aggregate pom. All the submodules will have received updated values from that properties file.

PS - in case anyone wonders why you wouldn't just define the properties in a parent pom, the issue there is that Maven doesn't support multiple inheritance, so what to do eg if you wanted to inherit from spring-boot-starter instead? You could make the parent inherit from that, but then what if not all the submodules wanted to inherit from spring-boot-starter but some do?

By using aggregation instead of inheritance, the above technique lets you synchronize your module versions without being straight-jacketed into a particular inheritance hierarchy.

Halimeda

Answer 4

This properties(dev.properties) file for build job.

<files>
   <file>dev.properties</file>
</files>

For dependency you need add like below in your pom.xml file.

<properties>

<org.aspectj.aspectjrt.version>1.6.11</org.aspectj.aspectjrt.version>
</properties>

Gehrke

How to make the pom file pick the version number from the property file ? – Impala