Flattening variables defined from external file using properties-maven-plugin

[MarcLadent]

I tried without success to flatten the revision tag using a variable defined into an external file and loaded through the properties-maven-plugin.

Output of message using echo-maven-plugin (com.github.ekryd.echo-maven-plugin) is working as expecting with variable coming form the external file being replaced as expected.

I tested different approach after looking at the source code. It seems that external properties are available into the resolvedPom (project model). But to use them we have to define the flatten descriptor to resolve.

So i tried this :

<pomElements>
   <version>resolve</version>
   <properties>resolve</properties>
</pomElements>

However, the flattened pom still use ${revision} and does not replace the value defined into the properties.

On resolve ( or any relevant new keyword) , would it be possible to look at the properties and replace any ${} by its value ?

I tried using java properties ( -D on command line) and replacement if working fine but performed by maven itself and before the start of its lifecycle !!

Please help me in case a workaround is available using Maven 3.5.2 , properties plugin 1.0.0 and flatten 1.0.1

[mariuszs]

The same is when you want to use version from git describe:

    <version>${revision}</version>

    <properties>
        <revision>${git.commit.id.describe-short}</revision>
    </properties>

...

                   <plugin>
                        <groupId>pl.project13.maven</groupId>
                        <artifactId>git-commit-id-plugin</artifactId>
                        <version>2.2.4</version>
                        <executions>
                            <execution>
                                <id>get-the-git-infos</id>
                                <goals>
                                    <goal>revision</goal>
                                </goals>
                                <phase>initialize</phase>
                            </execution>
                        </executions>
                    </plugin>
                    <!-- broken -->
                    <plugin>
                        <groupId>org.codehaus.mojo</groupId>
                        <artifactId>flatten-maven-plugin</artifactId>
                        <version>1.0.1</version>
                        <configuration>
                            <updatePomFile>true</updatePomFile>
                        </configuration>
                        <executions>
                            <execution>
                                <id>flatten</id>
                                <phase>process-resources</phase>
                                <goals>
                                    <goal>flatten</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>

[nerro]

Any idea why it doesn't work with git-commit-id-plugin? We are trying currently to solve this issue.

[lasselindqvist]

Instead of ${revision} just use ${git.commit.id.describe-short} and it should work? Maven would give you a warning but nothing else.

Otherwise if maven-git-commit-id-plugin allows it, instead of defining the value for git.commit.id.describe-short make it define revision directly.

[nerro]

@lasselindqvist, did you try it or simple guess? We have exact the same configuration as mariuszs and the maven version after flattening is ${git.commit.id.describe-short} (looks like property was not interpreted or expanded).

If you have any working solution for this, bring it on :smile:

[lasselindqvist]

It is only an educated guess since I don't have a full project I could test it on.

[mariuszs]

@lasselindqvist sorry, but your solution is not working, and writing something useless is not helping at all ;)

[TheSnoozer]

Hello, I'm not related to this project and thus not familiar with the code base.

By a very brief look it seems that this flatten plugin only respects properties set inside session.getUserProperties() and the properties set in System.properties (I think they come by default from maven). However properties stored only in project.properties are resulting in a flattern pom where the variable is unresolved.

Consider the following example:

<project>
   <properties>
      <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
      <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
      <revision>${git.commit.id}</revision>
   </properties>
   <plugins>
      <plugin>
         <groupId>org.codehaus.gmaven</groupId>
         <artifactId>gmaven-plugin</artifactId>
         <version>1.5</version>
         <executions>
            <execution>
               <id>set-custom-property</id>
               <phase>initialize</phase>
               <goals>
                  <goal>execute</goal>
               </goals>
               <configuration>
                  <source>
                  System.properties.put('git.commit.id', 'foo') // works as standalone
                  session.getUserProperties().put('git.commit.id', 'foo') // works as standalone
              project.properties.put('git.commit.id', 'bar') // doesn't work
                  </source>
               </configuration>
            </execution>
         </executions>
      </plugin>
      <plugin>
         <groupId>org.codehaus.mojo</groupId>
         <artifactId>flatten-maven-plugin</artifactId>
         <version>1.1.0</version>
         <configuration>
            <flattenedPomFilename>.flattened-pom.xml</flattenedPomFilename>
            <updatePomFile>true</updatePomFile>
         </configuration>
         <executions>
            <execution>
               <id>flatten</id>
               <phase>process-resources</phase>
               <goals>
                  <goal>flatten</goal>
               </goals>
            </execution>
         </executions>
      </plugin>
   </plugins>
</project>

For the git-commit-id-plugin I can certainly expose the variables so this project works. However I guess it would also be better if this projects respects more places where variables can be stored (like it is done in the sonar plugin)