Open pruthvi-rb opened 6 months ago
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.
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
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.
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.
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 versionWhereas 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 ArtifactoryExpected 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