Hi, I have faced the same problem recently on jgitver maven core dependency ( https://github.com/jgitver/jgitver-maven-plugin/issues/109). In fact, the problem popped up when a *fork* execution occures after that the pom file has been relocated. When this occures the basedir is computed as the directory containing the pom which is not what is expected and leads to issues. Unfortunatelly my plugin already calls the 'good' api by calling setPomFile when it can ( https://github.com/jgitver/jgitver-maven-plugin/blob/master/src/main/java/fr/brouillard/oss/jgitver/JGitverUtils.java#L127 ).
So if you have a plugin that fires a fork execution you should be able to reproduce. I have not tested yet the above fork scenario with pom relocation outside of project dir with flatten-maven-plugin. Regards, Matthieu On Sun, Jan 13, 2019 at 3:10 PM Mikael Åsberg <m.asberg.wa...@gmail.com> wrote: > Hi Hervé, and thanks for your reply! So it sounds like since > maven-shade-plugin still has not been updated to use the new API, the > problem should still be there. But did you check my test project? I thought > it would capture the problem, if it was still there and I understood it > correctly, but I guess the project is bogus somehow since it doesn't > capture the issue. I would like to understand how my test project is faulty > so I understand the issue properly. Is there a Jira for maven-shade-plugin > which tracks the issue (an issue which could be solved by using the new API > you mentioned)? > > Regards, Mikael > > On Sun, Jan 13, 2019, 10:43 Hervé BOUTEMY <herve.bout...@free.fr wrote: > > > Hi > > > > Good question: I did not yet find the official answer, but I can share > > what I > > know on this. > > > > flatten-maven-plugin has the exact same issue, and this was fixed in the > > past > > by adding a new API in Maven core (in 3.2.5) to be called by the plugin: > > see https://github.com/mojohaus/flatten-maven-plugin/pull/30 > > > > I just had a look at maven-shade-plugin source and found > "project.setFile( > > dependencyReducedPomLocation );": this call has not been replaced by > > setPomFile() API. > > That means that the limitation on the chosen directory should still be > here > > > > Hope this helps... > > > > Regards, > > > > Hervé > > > > Le mercredi 9 janvier 2019, 15:06:26 CET Mikael Åsberg a écrit : > > > Hi, the documentation for dependencyReducedPomLocation says: > > > "Where to put the dependency reduced pom. Note: setting a value for > > > this parameter with a directory other than ${basedir} will change the > > > value of ${basedir} for all executions that come after the shade > > > execution. This is often not what you want. This is considered an open > > > issue with this plugin." > > > > > > > > > https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#dependen > > > cyReducedPomLocation > > > > > > I created a small test project which performs a shade in the package > > > phase (with the dependencyReducedPomLocation set to the > > > ${project.build.directory} and then I print the value (using > > > gmavenplus-plugin) of ${project.basedir} in the verify phase (which > > > comes after package as you know). I don't see that the value of > > > basedir has changed (which is good), is this part of the documentation > > > incorrect or is my test project wrong (i.e., did I misunderstood the > > > possibly undesirable side-effect to ${basedir} by setting > > > dependencyReducedPomLocation)? > > > > > > You can find my test project here: > > https://github.com/masberg/mshadeissue > > > > > > - Mikael > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
