apache
[MSHADE-323] Flatten Maven Plugin conflicts with Maven Shade Plugin
lakunma opened MSHADE-323 and commented
When using Flatten Maven Plugin in the same project with Maven Shade Plugin then the dependency reduced POM is not flattened.
What i encountered that having flatten plugin configured according to https://maven.apache.org/maven-ci-friendly.html, and having shade plugin configured with the default settings to produce uber jar the ${revision} variable remains and gets installed/deployed within the final pom, thus making the pom in the repository invalid.
It seems that both plugins transform original pom. And then what gets installed in the last one, which is the 'shades' one. I'm not sure that's a bug (in a sense that it is shade's fault).
See also https://github.com/mojohaus/flatten-maven-plugin/issues/100
Remote Links:
6 votes, 6 watchers
Ilya Kasnacheev commented
This is a Shade bug, since it works the other way around: Flatten maven plugin will pick up changes made by Shade, but Shade will ignore changes made by Flatten.
James Z.M. Gao commented
Ilya Kasnacheev this pr makes it possible to chain the flatten and shade plugins on rewriting the project pom.
This pr does not change the originalModel. But imo the root cause of the conflicts should be the inconsistent of project.getOriginalModel() and readModel(project.getFile()). So every plugin rewriting the pom file should also update original model to reflect the new pom file content, whereas the flatten and shade plugins both lack this step after switching the project pom.
NB: The work around of invoking flatten in package phase after the shade plugin does not work when setting <useDependencyReducedPomInJar> true in the shade plugin, i.e., the pom in the shaded jar is still not processed by the flatten plugin.
Ilya Kasnacheev commented
Unfortunately I'm not a committer to Maven and can't carry modified Maven around. Still, thank you.
Jesse Glick commented
https://github.com/mojohaus/flatten-maven-plugin/releases/tag/flatten-maven-plugin-1.3.0