[ https://issues.apache.org/jira/browse/MNG-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16819040#comment-16819040 ]
Hudson commented on MNG-6405: ----------------------------- Build succeeded in Jenkins: Maven TLP » maven » master #196 See https://builds.apache.org/job/maven-box/job/maven/job/master/196/ > Incorrect basedir in forked executions when using flatten-maven-plugin with > custom outputDirectory > -------------------------------------------------------------------------------------------------- > > Key: MNG-6405 > URL: https://issues.apache.org/jira/browse/MNG-6405 > Project: Maven > Issue Type: Bug > Components: core > Affects Versions: 3.5.3 > Reporter: Jesse Glick > Assignee: Olivier Lamy (*$^¨%`£) > Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > For [JENKINS-51247|https://issues.jenkins-ci.org/browse/JENKINS-51247] I am > trying to use a variant of the tip shown > [here|https://github.com/mojohaus/flatten-maven-plugin/issues/53#issuecomment-340366191]: > 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 > {code} > 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! > {code} > 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? -- This message was sent by Atlassian JIRA (v7.6.3#76005)