> From: ctrue...@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 <and...@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.ham...@gmail.com [mailto:anders.g.ham...@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-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> >
