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/14 18:44:00 UTC
[jira] [Commented] (MNG-6405) Incorrect basedir in forked
executions when using flatten-maven-plugin with custom outputDirectory
[ https://issues.apache.org/jira/browse/MNG-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16474611#comment-16474611 ]
Jesse Glick commented on MNG-6405:
----------------------------------
If you are using both {{flatten-maven-plugin}} and {{maven-release-plugin}}, _and_ any plugins which rely on the basedir (such as {{frontend-maven-plugin}}), you may need to override the (poor?) choice in the superpom:
{code:xml}
<profile>
<id>fix-superpom-source-fork</id>
<activation>
<property>
<name>performRelease</name>
<value>true</value>
</property>
</activation>
<build>
<plugins>
<plugin>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<id>attach-sources</id>
<phase>DO-NOT-ACTUALLY-RUN</phase>
</execution>
<execution>
<id>attach-sources-no-fork</id>
<goals>
<goal>jar-no-fork</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
{code}
YMMV.
> 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
> Priority: Major
>
> 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)