How can I override maven property values set by properties-maven-plugin's read-project-properties goal?

Question

In one of our projects, we use the properties-maven-plugin's read-project-properties goal to read property values from a file which are then used for filtering resources. See this post for a discussion on the general purpose of this procedure.

We would like to override some of the values found in the file using a suitable profile defined in the developer specific settings.xml (the same way we override properties set in the POM).

This, however, does not work for the properties set by the properties-maven-plugin.

How can we achieve our goal?

As a work around, we are currently registering an additional, developer specific file with the properties-maven-plugin to achieve this effect but it would be much more convenient to use the regular way (profiles).

In more general terms, the question is: How do properties set by properties-maven-plugin's read-project-properties goal tie into the property definition precedence hierarchy of maven, which is described in this very helpful blog post.

I extracted the relevant elements of our POM into a toy project that demonstrates my issue. Here is the POM of the toy project:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>xxx</groupId>
  <artifactId>MavenTest</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <name>Maven Test</name>
  <description>A maven project to test filtering and the maven-properties-plugin</description>
  <build>
    <resources>
      <resource>
        <directory>src/main/resources</directory>
        <filtering>true</filtering>
      </resource>
    </resources>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>properties-maven-plugin</artifactId>
        <executions>
          <!-- Read properties from a file -->
          <execution>
            <id>load-filter-properties</id>
            <goals>
              <goal>read-project-properties</goal>
            </goals>
            <phase>initialize</phase>
            <configuration>
              <files>
                <file>filters/filterTest.properties</file>
              </files>
              <quiet>false</quiet>
            </configuration>
          </execution>
          <!-- The following execution is for debug purposes only -->
          <execution>
            <id>write-project-properties</id>
            <inherited>false</inherited>
            <goals>
              <goal>write-project-properties</goal>
            </goals>
            <phase>package</phase>
            <configuration>
              <outputFile>filters/project.properties</outputFile>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.12-beta-1</version>
    </dependency>
  </dependencies>
</project>

Answer 1

I think you will find the answer here:

Modifications of project properties that happen during project lifecycle have no effect on the effective pom – it is just too late. Examples of such modifications include groovy scripts (via gmaven-plugin) and properties loaded from external files via maven-properties-plugin. So, why do we need them at all? Since they can be used by other plugins in runtime, when they are read directly from properties collection during plugin invocation.

Since the properties are read after the usual resolution they just override whatever was set in profiles.