Description
For JENKINS-51247 I am trying to use a variant of the tip shown here: using flatten-maven-plugin with a generated POM file in the target directory. This works fine in almost all cases, since the plugin calls MavenProject.setPomFile, which leaves the basedir untouched.
Unfortunately it fails for mojos which rely on the basedir that are run inside a forked execution, as I found when accidentally using source:jar when source:jar-no-fork was what I wanted. (Ditto when using findbugs:check.) This seems to be because deepCopy still calls setFile, so the basedir of a cloned project is not the same as the original—it is always the parent directory of the POM file.
Fixing this should be trivial
diff --git a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java index 80a51935e..ee7a68635 100644 --- a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java +++ b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java @@ -1207,7 +1207,8 @@ private void deepCopy( MavenProject project ) // disown the parent // copy fields - setFile( project.getFile() ); + file = project.file; + basedir = project.basedir; // don't need a deep copy, they don't get modified or added/removed to/from - but make them unmodifiable to be // sure!
but I am unsure what the best approach is to validate the fix. A unit test in MavenProjectTest? An IT which calls flatten-maven-plugin, source:jar, and some other mojo TBD which is sensitive to project basedir? Both?
Attachments
Issue Links
- relates to
-
MNG-5940 Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM
- Closed
- links to