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 <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 > > > > >
