Regarding config param dependencyReducedPomLocation for maven-shade-plugin

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Regarding config param dependencyReducedPomLocation for maven-shade-plugin

Mikael Åsberg
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Regarding config param dependencyReducedPomLocation for maven-shade-plugin

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





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Regarding config param dependencyReducedPomLocation for maven-shade-plugin

Mikael Åsberg
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 <[hidden email] 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Regarding config param dependencyReducedPomLocation for maven-shade-plugin

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