Prevent interpolation of specific system properties (e.g. user.dir, java.home)

[Andrei-Pozolotin]

1. when using flatten with:

<pomElements>
   <profiles>keep</profiles>

2. and pom profile with:

<activation>
   <file>
      <exists>${user.dir}/pom-service.md</exists>

3. most profile variables are kept, but <exists> is interpolated:

   <activation>
      <file>
         <exists>/some/absolute/path/pom-service.md</exists>

[hohwille]

Indeed, I can see that behavior as unexpected or even more clear as a bug.
The question is: Should variable interpolation happen for

• no property at all?
• only specific standard properties (user.dir, java.home, etc.)?

[hohwille]

To answer my own question:
IMHO the interpolation should not depend on POM element but instead by system property. Here I start a blacklist of variables that should not be interpolated:

• user.dir
• user.language
• user.country
• user.name
• java.home
• java.io.tmpdir
• file.encoding
• file.separator
• line.separator
• path.separator
• java.version
• os.arch
• os.name
• os.version
• basedir
• project.* (to be discussed, but IMHO project.groupId, project.artirfactId, project.version, etc. should also not be interpolated even though there are rare situations where it could be beneficial.- e.g. when releasing parent POM used by children with different groupId.)

The main thing remaing are the custom properties defined in the properties section of the POM (or provided externally not in the list above).

[stonedu1011]

Is there any update on this issue?

We have a multi-module project serves as framework of another project and also provide common pom parent for the other project. There are couple of profiles defined in the pom with file activation.

We only plan to use this plugin for <flattenMode>resolveCiFriendliesOnly</flattenMode>. This bug is currently blocking us from using it. Any suggestions for workaround?

If the 1.2.0 is not going to get released soon, is there a plan to release a bug fixes (v1.1.1)?

I'd make a suggestion: when to-be-flattened pom is pom packaging, it might be served as parent of other project, so we need an option to keep everything untouched in profiles instead of blacklisted properties.

[stonedu1011]

Just want to add some information:

In my project described above, we don't use any properties but relative path to current project (this is equivalent to use ${basedir} ).

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>flatten-maven-plugin</artifactId>
    <version>1.1.0</version>
    <configuration>
        <updatePomFile>true</updatePomFile>
        <flattenMode>resolveCiFriendliesOnly</flattenMode>
    </configuration>
</plugin>

The profile looks like:

<profile>
    <id>dockerfile-update</id>
    <activation>
        <file>
            <exists>Dockerfile</exists>
        </file>
    </activation>
</profile>

And the published pom looks like

<profile>
    <id>dockerfile-update</id>
    <activation>
        <file>
            <exists>aboslute/path/resolved/on/building/machine/Dockerfile</exists>
        </file>
    </activation>
</profile>

[oburgosm]

What is the status of this issue?