Re: Regarding config param dependencyReducedPomLocation for maven-shade-plugin
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 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 > > 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 > > > > >
Re: Regarding config param dependencyReducedPomLocation for maven-shade-plugin
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 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 > >
Re: Regarding config param dependencyReducedPomLocation for maven-shade-plugin
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