You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Jesse Glick (JIRA)" <ji...@apache.org> on 2018/05/10 14:46:00 UTC

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

Jesse Glick created MNG-6405:
--------------------------------

             Summary: 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


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)