You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Mikael Åsberg <m....@gmail.com> on 2019/01/09 14:06:26 UTC
Regarding config param dependencyReducedPomLocation for maven-shade-plugin
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#dependencyReducedPomLocation
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Regarding config param dependencyReducedPomLocation for maven-shade-plugin
Posted by Matthieu BROUILLARD <ma...@brouillard.fr>.
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....@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.boutemy@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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
Re: Regarding config param dependencyReducedPomLocation for maven-shade-plugin
Posted by Mikael Åsberg <m....@gmail.com>.
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.boutemy@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Regarding config param dependencyReducedPomLocation for maven-shade-plugin
Posted by Hervé BOUTEMY <he...@free.fr>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org