[
https://issues.apache.org/jira/browse/MNG-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16822452#comment-16822452
]
Hudson commented on MNG-6405:
-----------------------------
Build succeeded in Jenkins: Maven TLP » maven » runITsWithJavaEA #29
See https://builds.apache.org/job/maven-box/job/maven/job/runITsWithJavaEA/29/
> 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)
