I also have an issue with the current behaviour. At least for me, all property values are interpolated in the flattened POM for all active profiles and not just ${revision}, ${sha1} and ${changelist}. Results for inactive profiles are fine.

This should be merged as it does exactly what I was expecting of resolveCiFriendliesOnly (and was surprised that it did more when I had activated a profile....).

I wanted to migrate back from the resolve-parent-version-maven-plugin to the flatten-maven-plugin and are now blocked by this issue. Could you please release a fixed version?

Related: I see the docs updates have not been pushed to http://www.mojohaus.org/flatten-maven-plugin/flatten-mojo.html yet. They would contain info about the resolveCiFriendliesOnly mode.

So resolveCiFriendliesOnly is supposed to only resolve revision, sha1 and changelist (see

We used this resolveCiFriendliesOnly mode, but the properties inherited from parent are resolved, and also all of the maven properties are resolved. Following are examples:
Resolved properties:

      <properties>
        <os.detected.name>linux</os.detected.name>
        <os.detected.arch>x86_64</os.detected.arch>
        <os.detected.release.like.rhel>true</os.detected.release.like.rhel>
        <os.detected.release.version>7.6</os.detected.release.version>
        <os.detected.classifier>linux-x86_64</os.detected.classifier>
        <skipTests>true</skipTests>
        <skipUnpack>true</skipUnpack>
        <os.detected.release.like.fedora>true</os.detected.release.like.fedora>
        <os.detected.release>rhel</os.detected.release>
      </properties>

Configuration of plugins

 <configuration>
                           <artifactItems>
                              <artifactItem>
                                  <groupId>${project.groupId}</groupId>
                                   <artifactId>${project.artifactId}</artifactId>
                                    <version>${project.version}</version>
                                     <classifier>tests</classifier>
                                     <outputDirectory>${project.build.testOutputDirectory}                          
                                     </outputDirectory>
                                 </artifactItem>
                           </artifactItems>
 </configuration>

Look forward to the new release with this feature, or maybe is it possible for us to specify which variables should be resolved?

By the way, I have checked the latest release of plugin (1.2.1) and the issue is not fixed yet.
Loop in @lasselindqvist
May you can help for the fix, thanks!

There is a work around just use this config:

<flattenMode>resolveCiFriendliesOnly</flattenMode>
<pomElements>
  <profiles/>
</pomElements>

you'll still get all of the resolveCiFriendliesOnly but profiles won't be resolved

@pnsantos unfortunately, your solution doesn't work as the profile's properties got resolved, e.g.
${project.build.directory}.
This is the complete showstopper; P0 bug!

This example pom file will demonstrate this issue https://github.com/marioja/mavenmodule/blob/maven-flatten-plugin/grandpa/pom.xml. If you run the process-resources phase you can see that the .flattened-pom.xml will have the destFile element in the plugin execution expanded. This expansion is what will be deployed to the artifact repository which is obviously not what is desired. Is someone looking into a fix? Will this sample project fix help to get it fix? This issue is a blocker for us.

The <pomElements><profiles/></pomElements> workaround does not work.

• Without the profiles pomElements the properties in the profile do not get interpolated but the properties in the profile build execution do get interpolated.
• If I add the profiles pomElements the reverse takes place, the properties get interpolated and the properties in the profile build execution do not get interpolated.
  There is no workaround and this is a blocker.

People, the flatten-maven-plugin is a very important plugin for enterprise CI build. Does anyone triage these tickets? It says above that it is currently unassigned. It would be extremely important to a lot of organisations to have this problem fixed and given that it has been opened for more than a year (July 2019) I am concerned that it may not get the attention it deserves. @lasselindqvist @pnsantos @NancyChunlan See my previous post for a quick sample that reproduces the issue.

If it is that important what about supporting some of the dev(s) which do this work in their spare time ... for example sponsoring dev(s) for their work for example with the money to be able to work a day per month or a days per week on that particular project?

@khmarbaise Karl, for starters I do not hold the purses. Second, you know how much bureaucracy is involved to have an organization "fund" an open source project even if limited and the chances of success are slim. Plus, have we come to that where open source project have to be funded to operate? No one is asking for an enterprise support service here so let's not get carried away. In @lasselindqvist 's own words, it should not be a huge amount of work if a sample was available. It is now so I am just trying to constructfully raise the profile of this issue.

If you or other do not try it the chance of being successful is zero.

Furthermore why not hiring a dev for a day per month or per week and let it work on the project? Not direct funding indirectly ...with official invoice etc.

Plus, have we come to that where open source project have to be funded to operate?

Hm... the problem with that is that many people thinking they are getting things (support / etc. ) for nothing ...

No one is asking for an enterprise support service here so let's not get carried away

Hm.. you requesting or others as well that:

People, the flatten-maven-plugin is a very important plugin for enterprise CI build.
Hm... sounds like it to me...

Furthermore in the end it does not matter if you are a starter or not. If you not holding the purses ok, but the companies you/others are working for might be the right one...

But OK I think I understand this thing. Bye.

@marioja so why was there no response to the question that was made 19 hours ago? Likely because personally I was sleeping then. After that I woke up and went to my day job. Probably similar reasons for other people who follow this repository.

Now I read the comment and might have some time to look into it. It is nice that there is a single pom replication possibility now. That might motivate me to look into it, write a failing IT and see if I can get it fixed. But also I might do other things this weekend, such as go to the movies or read a book.

If it happened that I did not fix it myself, but an external person or an organization provided a bugfix, I would be happy to help them write tests for it, merge the PR and release a new version.

But also since this is quite a difficult thing to fix and there is an easy workaround (do not use a profile, but allow skipping the plugin with a property), I don't consider this a high priority issue. If your company faces this problem and needs it solved fast, I suggest move the Jacoco plugin out of the profile, make it enabled by default and allow skipping it via a command line parameter.

Guys, sorry if I gave any impression that the people who generously give their time to support open source code are slackers. I never meant to imply this and I surely did not expect a fix to be coming in the hours after my post. The reason I made the second post is not because I thought that you guys were not responsive enough, quite the contrary, I know for myself that supporting open source is a thankless job and one has to find the time out of one's busy schedule to do it. I did the second post so that you would be notified and when you have the availability you could look into it, not so that you would act on it and try to fix it immediately. That would not be fair to you guys who do a great job in writing great software for everyone.

After ranting, time to get back to try to provide value here. Since my posts, I did not sit on my butt and I tried to debug it to try to come up with a fix myself. Here is what I know so far (my lack of familiarity with the code does not help):

The interpolate methods in CiInterpolatorImpl are not at fault. By the time these methods are called, the properties in the profile build invocation are already interpolated.
I am looking at the call on line 393 DefaultModelBuilder.java to see if the problem lies there. Before that call the resultModel contains a profile build plugin execution whose configuration has not yet been interpolated.

Will continue debugging and report back.

@lasselindqvist I was not aware of the workaround. I did not even try because I thought that the interpolation would work the same. Not sure if disable with a property would work in our case but I will try it.

The problem seems to occur when calling createResolvedPom on line 596 of FlattenMojo called from line 568 in createFlattenedPom. I do not understand it yet but the Model returned by createResolvedPom will have the properties interpolated in the profile build plugin execution. Continuing on with my research.

My lack of knowledge of the code is not helping here, but the problem probably takes place elsewhere than the method createResolvedPom. The issue is that the FlattenMojo project field (MavenProject type) contains an interpolated destFile element in the profile build plugin execution upon entry to the createResolvedPom and that is what is used to return a model.

It looks like when the FlattenMojo starts the execute method, the project field contains a model that has already been interpolated. I am not sure how to debug this as I am not familiar with maven plugins and the @parameter annotation.

I am puzzled. The FlattenMojo injected field project contains a model that has been interpolated. The execute method seems to read the original pom file and create a model. Could it be that the method createResolvedPom should use the read model instead of the FlattenMojo project's model to do its work? As I said, I am not familiar enough with the code to understand the implications.

It seems that version 1.2.7 of the plugin fixes this problem. At least in my local testing the following plugin definition produced a .flattened-pom.xml with no properties being interpolated apart from the version tag:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>flatten-maven-plugin</artifactId>
    <version>1.2.7</version>
    <configuration>
        <flattenMode>resolveCiFriendliesOnly</flattenMode>
        <updatePomFile>true</updatePomFile>
    </configuration>
    <executions>
        <execution>
            <id>flatten</id>
            <phase>process-resources</phase>
            <goals>
                <goal>flatten</goal>
            </goals>
        </execution>
        <execution>
            <id>flatten.clean</id>
            <phase>clean</phase>
            <goals>
                <goal>clean</goal>
            </goals>
        </execution>
    </executions>
</plugin>

btw, the suggested workaround from earlier:

<pomElements>
    <profiles/>
</pomElements>

worked for properties in the profile activation tags, but not for values in the plugins itself.

Also, it seems that the plugin website at https://www.mojohaus.org/flatten-maven-plugin/index.html is still showing 1.2.2 as the latest version.

Seems to work as intended with version 1.2.7 for me as well.
Would be nice if the plugin website could be updated. :)

After last comments I assume that is resolved, so I close it.