[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=17069829#comment-17069829
]
Hudson commented on MNG-6405:
-
Build failed in Jenkins: Maven TLP » maven-studies » maven-metrics #4
See
https://builds.apache.org/job/maven-box/job/maven-studies/job/maven-metrics/4/
> 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
> Fix For: 3.6.2
>
> 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
(v8.3.4#803005)
[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=16978818#comment-16978818
]
Olivier Lamy commented on MNG-6405:
---
I guess so as the pr has been merged. I have just fixed the Fix Version/s field.
> 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
> Fix For: 3.6.2
>
> 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
(v8.3.4#803005)
[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=16978470#comment-16978470
]
Jesse Glick commented on MNG-6405:
--
It seems this was released in 3.6.2?
> 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
(v8.3.4#803005)
[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=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)
[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=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)
[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=16733584#comment-16733584
]
Jesse Glick commented on MNG-6405:
--
Filed [PR 225|https://github.com/apache/maven/pull/225] with the patch above.
> 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
> Time Spent: 10m
> 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)
[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=16522608#comment-16522608
]
Jesse Glick commented on MNG-6405:
--
No, the bug in core remains. I was just noting that _one trigger_ for it—the
choice of mojo in the superpom—is now removed. The bug will continue to be a
problem whenever anyone uses any mojo which requests a forked execution.
> 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)
[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=16522607#comment-16522607
]
Robert Scholte commented on MNG-6405:
-
In other words this one can be closed?
> 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)
[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=16522321#comment-16522321
]
Jesse Glick commented on MNG-6405:
--
The superpom has evidently been fixed in Maven 3.5.4, so at least now any
problems would come from use of forked executions in your _own_ POM(s).
> 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)
[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}
fix-superpom-source-fork
performRelease
true
maven-source-plugin
attach-sources
DO-NOT-ACTUALLY-RUN
attach-sources-no-fork
jar-no-fork
{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)
