You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Matthew Amos <MA...@scottlogic.com> on 2018/06/08 12:39:39 UTC
Extending the shade plugin to support war files
At present the shade plugin doesn't really support war files. The classes that are shaded are written into the root of the output artefact, and the WEB-INF/classes path component is mistakenly taken to be part of the package name.
I have created a fork of the repository and added a new configuration setting:
<rootDirInArchive>WEB-INF/classes</rootDirInArchive>
With this set, the project artefact that is treated specially when compared to its dependencies. The result is that the shaded and potentially relocated classes and resources are added to the WEB-INF/classes folder. The correct behaviour is taken to correctly identify and deal with duplicates using the existing logic i.e. to avoid any exceptions from duplicate entries in the resultant war.
I have a rudimentary test case, and am successfully using this in one of my own projects. Before I complete these tests, open a Jira, and make a pull request, I would like to ensure that the feature would be appreciated.
I am interested to know why this behaviour has never been added previously.
Would the more flexible option of specifying the root directory in the archive be preferred? Or would it be preferable to have either a Boolean <warArtifact>true</warArtifact>, or even to do this automatically based on the file extension of the project artifact?
At present I remove the shaded artefacts in the maven-war-plugin using the packagingExcludes config. I could also extend the shade plugin to do this automatically. Would that feature be required for me to contribute?
I appreciate your input and feedback
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Extending the shade plugin to support war files
Posted by .
As I say I have dealt with those issues and have this working:
https://github.com/blackmamo/maven-shade-plugin
I just need to add some better tests, and apply any feedback from others. I tried creating a shaded jar and including it in my war, but my application server seemed to be incapable of picking up the EJB annotations in that scenario.
Do you know of an example of someone else taking the jar + war approach?
I could take a look and see what I did wrong in my previous attempt
On 2018/06/08 17:48:08, "Robert Scholte" <rf...@apache.org> wrote:
> The idea is there already for a long time, MSHADE-87 [1]
> After some time my conclusion was, that in the end it is easier and more
> reliable to add a shaded jar to the webarchive instead of trying to solve
> this within the war.
> This doesn't mean that it could be supported by the maven-shade-plugin,
> but it requires quite some changes to the filters, etc because of the
> change of the output location.
>
> thanks,
> Robert
>
> [1] https://issues.apache.org/jira/browse/MSHADE-87
>
> On Fri, 08 Jun 2018 14:39:39 +0200, Matthew Amos <MA...@scottlogic.com>
> wrote:
>
> > At present the shade plugin doesn't really support war files. The
> > classes that are shaded are written into the root of the output
> > artefact, and the WEB-INF/classes path component is mistakenly taken to
> > be part of the package name.
> >
> > I have created a fork of the repository and added a new configuration
> > setting:
> >
> > <rootDirInArchive>WEB-INF/classes</rootDirInArchive>
> >
> > With this set, the project artefact that is treated specially when
> > compared to its dependencies. The result is that the shaded and
> > potentially relocated classes and resources are added to the
> > WEB-INF/classes folder. The correct behaviour is taken to correctly
> > identify and deal with duplicates using the existing logic i.e. to avoid
> > any exceptions from duplicate entries in the resultant war.
> >
> > I have a rudimentary test case, and am successfully using this in one of
> > my own projects. Before I complete these tests, open a Jira, and make a
> > pull request, I would like to ensure that the feature would be
> > appreciated.
> >
> > I am interested to know why this behaviour has never been added
> > previously.
> >
> > Would the more flexible option of specifying the root directory in the
> > archive be preferred? Or would it be preferable to have either a Boolean
> > <warArtifact>true</warArtifact>, or even to do this automatically based
> > on the file extension of the project artifact?
> >
> > At present I remove the shaded artefacts in the maven-war-plugin using
> > the packagingExcludes config. I could also extend the shade plugin to do
> > this automatically. Would that feature be required for me to contribute?
> >
> > I appreciate your input and feedback
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Extending the shade plugin to support war files
Posted by Robert Scholte <rf...@apache.org>.
The idea is there already for a long time, MSHADE-87 [1]
After some time my conclusion was, that in the end it is easier and more
reliable to add a shaded jar to the webarchive instead of trying to solve
this within the war.
This doesn't mean that it could be supported by the maven-shade-plugin,
but it requires quite some changes to the filters, etc because of the
change of the output location.
thanks,
Robert
[1] https://issues.apache.org/jira/browse/MSHADE-87
On Fri, 08 Jun 2018 14:39:39 +0200, Matthew Amos <MA...@scottlogic.com>
wrote:
> At present the shade plugin doesn't really support war files. The
> classes that are shaded are written into the root of the output
> artefact, and the WEB-INF/classes path component is mistakenly taken to
> be part of the package name.
>
> I have created a fork of the repository and added a new configuration
> setting:
>
> <rootDirInArchive>WEB-INF/classes</rootDirInArchive>
>
> With this set, the project artefact that is treated specially when
> compared to its dependencies. The result is that the shaded and
> potentially relocated classes and resources are added to the
> WEB-INF/classes folder. The correct behaviour is taken to correctly
> identify and deal with duplicates using the existing logic i.e. to avoid
> any exceptions from duplicate entries in the resultant war.
>
> I have a rudimentary test case, and am successfully using this in one of
> my own projects. Before I complete these tests, open a Jira, and make a
> pull request, I would like to ensure that the feature would be
> appreciated.
>
> I am interested to know why this behaviour has never been added
> previously.
>
> Would the more flexible option of specifying the root directory in the
> archive be preferred? Or would it be preferable to have either a Boolean
> <warArtifact>true</warArtifact>, or even to do this automatically based
> on the file extension of the project artifact?
>
> At present I remove the shaded artefacts in the maven-war-plugin using
> the packagingExcludes config. I could also extend the shade plugin to do
> this automatically. Would that feature be required for me to contribute?
>
> I appreciate your input and feedback
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org