'jf mvn' will not resolve variables in the deployed pom to Artifactory

[pruthvi-rb]

Describe the bug

Maven replaces ${revision} version in POM when installing / deploying artifacts. However when using "jf mvn" it fails to replace the revision in the deployed pom to Artifactory

Current behavior

The published pom in the Artifactory ends up having POM containing ${revision} has version

Reproduction steps

1. Clone a sample maven project and update the artifacts to predefined variables (like {revision}) instead of actual value in the pom.xml file as shown here.

<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>com.example</groupId>
  <artifactId>my-maven-project</artifactId>
  <version>${revision}</version>
  <packaging>jar</packaging>
……………………………………….

2. Added the extension(https://github.com/jcgay/unique-revision-maven-filtering) which replaces the ${revision} version in POM to actual value to the pom.xml file in target folder when installing / deploying the artifacts.

3. Deploy the project to the Artifactory using jf mvn
   When we run the below command using the jf wrapper
   jf mvn --build-name=test --build-number=1 --detailed-summary -U -Drevision=1.0.0-SNAPSHOT clean install
   The published pom in the Artifactory ends up having POM containing ${revision} has version

4. Whereas when we just use mvn without "jf"
   mvn -Drevision=1.0.0-SNAPSHOT clean deploy
   The revision is replaced with the one passed as argument in the deployed pom to the Artifactory

Expected behavior

"jf mvn" should be able to resolve version in the published pom like just "mvn"

JFrog CLI version

latest

Operating system type and version

macOS

JFrog Artifactory version

SaaS latest

JFrog Xray version

No response

Attaching screenshots of deployed pom files to Artifactory.
When using mvn deploy

When using jf mvn

[bedge]

This appears to be a problem with the jf mvn not considering (ie: ignoring) mvn extensions in .mvn/extensions.xml

Note that for this particular case, the unresolved variables, one could also use the flatten-maven-plugin to accomplish the same thing without relying on extensions.
I expect I'm effectively killing off any potential fix here by providing a work-around as they can now say "you just need to ..." as described above.

However, while I'm at it, let me propose an alternate fix that addresses both cases:

It would be nice to get the flatten-maven-plugin considered as something that could be applied by the jf mvn invoker such that one could provide a plugin cfg to jf mvn via a command line arg.

Or, to say it another way, allow the jf mvn invoker to inject additional maven plugins via XML fragments into the effective pom.

eg: Add a new --plugin <xml file> arg to jf mvn:

eg:

jf mvn --plugin flatten-maven-plugin.xml .... <other args>

Where:
flatten-maven-plugin.xml contains:

            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>flatten-maven-plugin</artifactId>
                <version>1.6.0</version>
                <configuration>
                    <flattenMode>bom</flattenMode>
                    <flattenDependencyMode>all</flattenDependencyMode>
                    <keepCommentsInPom>true</keepCommentsInPom>
                </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>

... or something like that.

This way, for cases where one is using a common GitHub actions workflow, one can add this in one place to address the lack of maven extension processing that would otherwise need to be fixed in every single maven build cfg.

This would be a far less invasive fix than needing to embed the flatten-maven-plugin in every place where it is now needed.