shade plugin usage

[Richard Sand <rs...@idfconnect.com>]

I've a project that uses shade to create an uberjar - since I want that
uberjar artifact to be available for use in other projects, does it make
sense to *not* attach the artifact in shade, but rather have shade create
the uberjar and dependency-reduced-pom, and then use install:install-file to
grab the uberjar and drp.xml and install with a new unique artifactid (as
opposed to a classifier of the original artifact)?

Still feeling my way down the Maven Way...

-Richard



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: shade plugin usage

[Martin Gainty <mg...@hotmail.com>]

 
> From: ctrueden@wisc.edu
> Date: Thu, 5 Sep 2013 10:37:34 -0500
> Subject: Re: shade plugin usage
> To: users@maven.apache.org
> 
> Hi Anders,
> 
> > Help the Java community kill all überjars...
> 
> Personally, I am a fan of uberjars MG>+1 > as long as the encapsulated dependencies
> are shaded to avoid package clashes. Then you can use multiple dependency
> versions without crazy classloading like OSGi does. I used this feature
> just the other day when I needed to invoke Jython from a JVM that had an
> incompatible version of ASM on the classpath already. Fortunately, the
> Jython developers provided a shaded uberjar (which they call "standalone")
> which did the trick.
> 
> I've also spent lots of hours troubleshooting "NoSuchMethodError"MG>*usually* Dependency Version Mismatch  and
> "ClassNotFoundException" MG>*usually* a Dependency Version Mismatch or the dependency is missing 
MG>(mvn dependency:tree will identify the culprit) bug reports in user installations of our
> applications which developed "JAR skew" between dependencies. Uberjars
> (when done carefully) avoid that mess.
> 
> Of course there are downsides too, but I wouldn't say uberjars are always a
> bad idea. The nastiest thing about them is really when the producers
> *don't* shade the dependency packages.MG>what i've seen is the commercial codehauses 'brand' base packages with their company MG>e.g. sonatype brands a lot of the googlecode librariesMG>haven't seen any other reason (other than package branding) for implementing shading ..
> 
> Regards,
> Curtis>MG>Regards
MG>Martin-
> 
> 
> On Thu, Sep 5, 2013 at 1:18 AM, Anders Hammar <an...@hammar.net> wrote:
> 
> > Help the Java community kill all überjars...
> >
> > /Anders
> >
> >
> > On Thu, Sep 5, 2013 at 5:21 AM, Richard Sand <rs...@idfconnect.com> wrote:
> >
> > > Hi Anders - thanks for your reply. I agree with your advice - for this
> > > particular project artifact is a case where we want to offer both
> > options,
> > > and the uberjar is mainly an aggregation of our product apis. But I
> > > definitely understand the danger you are describing.
> > >
> > > -Richard
> > >
> > >
> > > -----Original Message-----
> > > From: anders.g.hammar@gmail.com [mailto:anders.g.hammar@gmail.com] On
> > > Behalf
> > > Of Anders Hammar
> > > Sent: Wednesday, September 04, 2013 2:08 AM
> > > To: Maven Users List
> > > Subject: Re: shade plugin usage
> > >
> > > First, try to stay away from the überjar path. It's normally not the way
> > to
> > > go today, but you should use the jar and it's dependencies instead. I've
> > > seen many case where people use a überjar just to try to make their life
> > > simpler but ending up with other issues instead. A proper classpath is
> > the
> > > way to go in my opinion.
> > >
> > > I guess your approach of deploying the überjar and a dep-reduced-pom
> > would
> > > work, but please remember to deploy it to your remote repo as well (and
> > not
> > > just your local repo). Somewhere in the back of my head I recall a
> > similar
> > > discussion earlier. Not sure if someone brought up any issues though.
> > > Having said that, the reason for deploying the überjar at a separate
> > > coordinate would be to have a separate pom with reduced deps. This
> > > indicates
> > > that you plan on use the pom to get the dependencies and in that case you
> > > should try to stick with the original jar instead and work with the
> > proper
> > > set of deps.
> > >
> > > /Anders
> > >
> > >
> > > On Wed, Sep 4, 2013 at 7:42 AM, Richard Sand <rs...@idfconnect.com>
> > wrote:
> > >
> > > > I've a project that uses shade to create an uberjar - since I want
> > > > that uberjar artifact to be available for use in other projects, does
> > > > it make sense to *not* attach the artifact in shade, but rather have
> > > > shade create the uberjar and dependency-reduced-pom, and then use
> > > > install:install-file to grab the uberjar and drp.xml and install with
> > > > a new unique artifactid (as opposed to a classifier of the original
> > > > artifact)?
> > > >
> > > > Still feeling my way down the Maven Way...
> > > >
> > > > -Richard
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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: shade plugin usage

[Curtis Rueden <ct...@wisc.edu>]

Hi Anders,

> Help the Java community kill all überjars...

Personally, I am a fan of uberjars as long as the encapsulated dependencies
are shaded to avoid package clashes. Then you can use multiple dependency
versions without crazy classloading like OSGi does. I used this feature
just the other day when I needed to invoke Jython from a JVM that had an
incompatible version of ASM on the classpath already. Fortunately, the
Jython developers provided a shaded uberjar (which they call "standalone")
which did the trick.

I've also spent lots of hours troubleshooting "NoSuchMethodError" and
"ClassNotFoundException" bug reports in user installations of our
applications which developed "JAR skew" between dependencies. Uberjars
(when done carefully) avoid that mess.

Of course there are downsides too, but I wouldn't say uberjars are always a
bad idea. The nastiest thing about them is really when the producers
*don't* shade the dependency packages.

Regards,
Curtis


On Thu, Sep 5, 2013 at 1:18 AM, Anders Hammar <an...@hammar.net> wrote:

> Help the Java community kill all überjars...
>
> /Anders
>
>
> On Thu, Sep 5, 2013 at 5:21 AM, Richard Sand <rs...@idfconnect.com> wrote:
>
> > Hi Anders - thanks for your reply. I agree with your advice - for this
> > particular project artifact is a case where we want to offer both
> options,
> > and the uberjar is mainly an aggregation of our product apis. But I
> > definitely understand the danger you are describing.
> >
> > -Richard
> >
> >
> > -----Original Message-----
> > From: anders.g.hammar@gmail.com [mailto:anders.g.hammar@gmail.com] On
> > Behalf
> > Of Anders Hammar
> > Sent: Wednesday, September 04, 2013 2:08 AM
> > To: Maven Users List
> > Subject: Re: shade plugin usage
> >
> > First, try to stay away from the überjar path. It's normally not the way
> to
> > go today, but you should use the jar and it's dependencies instead. I've
> > seen many case where people use a überjar just to try to make their life
> > simpler but ending up with other issues instead. A proper classpath is
> the
> > way to go in my opinion.
> >
> > I guess your approach of deploying the überjar and a dep-reduced-pom
> would
> > work, but please remember to deploy it to your remote repo as well (and
> not
> > just your local repo). Somewhere in the back of my head I recall a
> similar
> > discussion earlier. Not sure if someone brought up any issues though.
> > Having said that, the reason for deploying the überjar at a separate
> > coordinate would be to have a separate pom with reduced deps. This
> > indicates
> > that you plan on use the pom to get the dependencies and in that case you
> > should try to stick with the original jar instead and work with the
> proper
> > set of deps.
> >
> > /Anders
> >
> >
> > On Wed, Sep 4, 2013 at 7:42 AM, Richard Sand <rs...@idfconnect.com>
> wrote:
> >
> > > I've a project that uses shade to create an uberjar - since I want
> > > that uberjar artifact to be available for use in other projects, does
> > > it make sense to *not* attach the artifact in shade, but rather have
> > > shade create the uberjar and dependency-reduced-pom, and then use
> > > install:install-file to grab the uberjar and drp.xml and install with
> > > a new unique artifactid (as opposed to a classifier of the original
> > > artifact)?
> > >
> > > Still feeling my way down the Maven Way...
> > >
> > > -Richard
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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: shade plugin usage

[Anders Hammar <an...@hammar.net>]

Help the Java community kill all überjars...

/Anders


On Thu, Sep 5, 2013 at 5:21 AM, Richard Sand <rs...@idfconnect.com> wrote:

> Hi Anders - thanks for your reply. I agree with your advice - for this
> particular project artifact is a case where we want to offer both options,
> and the uberjar is mainly an aggregation of our product apis. But I
> definitely understand the danger you are describing.
>
> -Richard
>
>
> -----Original Message-----
> From: anders.g.hammar@gmail.com [mailto:anders.g.hammar@gmail.com] On
> Behalf
> Of Anders Hammar
> Sent: Wednesday, September 04, 2013 2:08 AM
> To: Maven Users List
> Subject: Re: shade plugin usage
>
> First, try to stay away from the überjar path. It's normally not the way to
> go today, but you should use the jar and it's dependencies instead. I've
> seen many case where people use a überjar just to try to make their life
> simpler but ending up with other issues instead. A proper classpath is the
> way to go in my opinion.
>
> I guess your approach of deploying the überjar and a dep-reduced-pom would
> work, but please remember to deploy it to your remote repo as well (and not
> just your local repo). Somewhere in the back of my head I recall a similar
> discussion earlier. Not sure if someone brought up any issues though.
> Having said that, the reason for deploying the überjar at a separate
> coordinate would be to have a separate pom with reduced deps. This
> indicates
> that you plan on use the pom to get the dependencies and in that case you
> should try to stick with the original jar instead and work with the proper
> set of deps.
>
> /Anders
>
>
> On Wed, Sep 4, 2013 at 7:42 AM, Richard Sand <rs...@idfconnect.com> wrote:
>
> > I've a project that uses shade to create an uberjar - since I want
> > that uberjar artifact to be available for use in other projects, does
> > it make sense to *not* attach the artifact in shade, but rather have
> > shade create the uberjar and dependency-reduced-pom, and then use
> > install:install-file to grab the uberjar and drp.xml and install with
> > a new unique artifactid (as opposed to a classifier of the original
> > artifact)?
> >
> > Still feeling my way down the Maven Way...
> >
> > -Richard
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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: shade plugin usage

[Richard Sand <rs...@idfconnect.com>]

Hi Anders - thanks for your reply. I agree with your advice - for this
particular project artifact is a case where we want to offer both options,
and the uberjar is mainly an aggregation of our product apis. But I
definitely understand the danger you are describing.

-Richard


-----Original Message-----
From: anders.g.hammar@gmail.com [mailto:anders.g.hammar@gmail.com] On Behalf
Of Anders Hammar
Sent: Wednesday, September 04, 2013 2:08 AM
To: Maven Users List
Subject: Re: shade plugin usage

First, try to stay away from the überjar path. It's normally not the way to
go today, but you should use the jar and it's dependencies instead. I've
seen many case where people use a überjar just to try to make their life
simpler but ending up with other issues instead. A proper classpath is the
way to go in my opinion.

I guess your approach of deploying the überjar and a dep-reduced-pom would
work, but please remember to deploy it to your remote repo as well (and not
just your local repo). Somewhere in the back of my head I recall a similar
discussion earlier. Not sure if someone brought up any issues though.
Having said that, the reason for deploying the überjar at a separate
coordinate would be to have a separate pom with reduced deps. This indicates
that you plan on use the pom to get the dependencies and in that case you
should try to stick with the original jar instead and work with the proper
set of deps.

/Anders


On Wed, Sep 4, 2013 at 7:42 AM, Richard Sand <rs...@idfconnect.com> wrote:

> I've a project that uses shade to create an uberjar - since I want 
> that uberjar artifact to be available for use in other projects, does 
> it make sense to *not* attach the artifact in shade, but rather have 
> shade create the uberjar and dependency-reduced-pom, and then use 
> install:install-file to grab the uberjar and drp.xml and install with 
> a new unique artifactid (as opposed to a classifier of the original 
> artifact)?
>
> Still feeling my way down the Maven Way...
>
> -Richard
>
>
>
> ---------------------------------------------------------------------
> 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: shade plugin usage

[Anders Hammar <an...@hammar.net>]

First, try to stay away from the überjar path. It's normally not the way to
go today, but you should use the jar and it's dependencies instead. I've
seen many case where people use a überjar just to try to make their life
simpler but ending up with other issues instead. A proper classpath is the
way to go in my opinion.

I guess your approach of deploying the überjar and a dep-reduced-pom would
work, but please remember to deploy it to your remote repo as well (and not
just your local repo). Somewhere in the back of my head I recall a similar
discussion earlier. Not sure if someone brought up any issues though.
Having said that, the reason for deploying the überjar at a separate
coordinate would be to have a separate pom with reduced deps. This
indicates that you plan on use the pom to get the dependencies and in that
case you should try to stick with the original jar instead and work with
the proper set of deps.

/Anders


On Wed, Sep 4, 2013 at 7:42 AM, Richard Sand <rs...@idfconnect.com> wrote:

> I've a project that uses shade to create an uberjar - since I want that
> uberjar artifact to be available for use in other projects, does it make
> sense to *not* attach the artifact in shade, but rather have shade create
> the uberjar and dependency-reduced-pom, and then use install:install-file
> to
> grab the uberjar and drp.xml and install with a new unique artifactid (as
> opposed to a classifier of the original artifact)?
>
> Still feeling my way down the Maven Way...
>
> -Richard
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>