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 <[email protected] 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
