[jira] [Assigned] (MNG-6405) Incorrect basedir in forked executions when using flatten-maven-plugin with custom outputDirectory

["Olivier Lamy (*$^¨%`£ JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MNG-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Olivier Lamy (*$^¨%`£) reassigned MNG-6405:
-------------------------------------------

    Assignee: Olivier Lamy (*$^¨%`£)

> 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)