one jar to rule them all

[Nimret Sandhu]

fyi for those interested in learning more about the maven shade plugin or
the fun to be had when creating a command line app which needs to do funky
classpath fun to accomodate conflicting dependencies ala automatic
dependency resolution frameworks like maven, etc:

http://www.javacodegeeks.com/2013/01/one-jar-to-rule-them-all.html

fun read :)
-
Nimret Sandhu
http://www.nimret.org

[Dhilipan Manoharan]

 Are there any weekend events planned ?



________________________________
From: Nimret Sandhu <nimret-rf+Eeaps6PzQT0dZR+***@public.gmane.org>
To: "seajug-***@public.gmane.org" <seajug-***@public.gmane.org>
Sent: Thursday, 24 October 2013 4:05 PM
Subject: [seajug] one jar to rule them all

 
fyi for those interested in learning more about the maven shade plugin or the fun to be had when creating a command line app which needs to do funky classpath fun to accomodate conflicting dependencies ala automatic dependency resolution frameworks like maven, etc:

http://www.javacodegeeks.com/2013/01/one-jar-to-rule-them-all.html

fun read :)
-Nimret Sandhuhttp://www.nimret.org/

[Nimret Sandhu]

No. We meet on the 3rd Tuesday of each month at Disney in downtown Seattle.
We are going to meet at Expedia in Bellevue for November though.

Nimret

Post by Dhilipan Manoharan
Are there any weekend events planned ?
*Sent:* Thursday, 24 October 2013 4:05 PM
*Subject:* [seajug] one jar to rule them all
**
fyi for those interested in learning more about the maven shade plugin or
the fun to be had when creating a command line app which needs to do funky
classpath fun to accomodate conflicting dependencies ala automatic
http://www.javacodegeeks.com/2013/01/one-jar-to-rule-them-all.html
fun read :)
-
Nimret Sandhu**http://www.nimret.org/
****

[Stuart Maclean]

A nice read, but note that someone commented on the tricky part of
packaging content from many jars into one uber-jar. For instance, what
about duplicated resource names??

I have found a nice middle ground. In the 'main' jar, you define in its
Manifest a class-path variable which lists the other, dependent jars.
These then have to be found in the same dir as the initial main jar was
located. I can then add "." to this class-path variable. This allows me
to 'extract' any config files that are located by their loader code
using the classpath. log4j springs to mind, it wants to load its
log4j.properties file from the classpath, which, if you have a monster
uber-jar, means burying that prop file in the jar. Having it on the
filesystem but still loadable via the classpath means you can tell your
'user' to 'edit the log4j.properties file in the directory where all the
jars are, replacing any log level with th word DEBUG'. OK, that's a
stretch but at least it doesn't involve unbundling the uber-jar, editing
the log4.properties file and re-bundling it all back up.

The flip side of the 'many jars + config files' is of course that they
all need packaging up, probably in a ZIP. But with some form of README
likely bundled anyway, this isn't such a big deal.
And of course there is a security hole in placing "." on the classpath,
so it should be listed AFTER all the dependent jars (which, btw Maven's
dependency plugin can derive) else you could have trojan classes being
loaded ahead of intended ones.

So my 2 cents is to actually AVOID the uber-jar solution where possible,
but DO supply all the code required by your application.

Stuart


------------------------------------

[Jason Osgood]

Hi Nimret.


We just had an inter-team presentation on the shade plugin. As a means to customize the base product for use by various institutions. The enthusiasm was palpable. I was aghast. I’m literally dumbfounded that someone created the shade plugin.

Our standard “stone soup” software stack takes advantage of all the awesomeness of Spring, dependency injection, inversion of control, overrides, abstract beans and cut points for superclassing, aspectJ for god knows what, and loosely layered properties files (with undocumented precedence). Of course, we have nested POMs gallore.

With so much awesomeness, I guess someones felt it was unforgivable to not have invited the classpath hacking strategy to the party too.

Conflicting dependencies? What am I missing here? Why would anyone ever permit conflicting dependencies? Isn’t that what Maven and Ivy and whatever are supposed to handle? If a project has conflicting dependencies, what’s the point of using maven? To automate the dysfunction?

The shade plugin is a test. It’s the software engineering god’s way of telling you you’re doing it wrong. And by “it”, I mean pretty much everything. To use shade is to forfeit any claim to be doing “engineering”.

IMHO, of course.


Cheers, Jason

Post by Nimret Sandhu
http://www.javacodegeeks.com/2013/01/one-jar-to-rule-them-all.html
fun read :)
-
Nimret Sandhu
http://www.nimret.org

[Eric Jain]

Conflicting dependencies? What am I missing here? Why would anyone ever permit conflicting dependencies? Isn’t that what Maven and Ivy and whatever are supposed to handle? If a project has conflicting dependencies, what’s the point of using maven? To automate the dysfunction?

Maven or Ivy won't help if two jars use two different, incompatible
versions of a third jar.

Distributing shady jars is an ugly hack, but simpler (and more
popular) than OSGi, which is what the engineering gods want you to
use.

[P.Hill]

I'm not sure about an app jar, but I saw a shady jar put to reasonable
use (for some definition of reasonable) in a library jar which was using
_one_ other library.
They 'shaded' the 2nd library, so they could use what the 1st library
builders knew to work. Everyone else including other libraries and the
application had to find another copy of those 2nd internally used
classes if they had use for them.

Like a lot of tools it was better used in one focused use, but I'm sure
someone somewhere has made a maven plug in that shades various
combinations of jars, so they can all play together. Yikes!

-Paul

Post by Jason Osgood

Post by Jason Osgood
Conflicting dependencies? What am I missing here? Why would anyone

ever permit conflicting dependencies?

[...]

Post by Jason Osgood
Distributing shady jars is an ugly hack, but simpler (and more
popular) than OSGi, which is what the engineering gods want you to
use.
--
Eric Jain
zenobase.com -- What do you want to track today?

[Stuart Maclean]

A nice read, but note that someone commented on the tricky part of
packaging content from many jars into one uber-jar. For instance, what
about duplicated resource names??

I have found a nice middle ground. In the 'main' jar, you define in its
Manifest a class-path variable which lists the other, dependent jars.
These then have to be found in the same dir as the initial main jar was
located. I can then add "." to this class-path variable. This allows me
to 'extract' any config files that are located by their loader code
using the classpath. log4j springs to mind, it wants to load its
log4j.properties file from the classpath, which, if you have a monster
uber-jar, means burying that prop file in the jar. Having it on the
filesystem but still loadable via the classpath means you can tell your
'user' to 'edit the log4j.properties file in the directory where all the
jars are, replacing any log level with th word DEBUG'. OK, that's a
stretch but at least it doesn't involve unbundling the uber-jar, editing
the log4.properties file and re-bundling it all back up.

The flip side of the 'many jars + config files' is of course that they
all need packaging up, probably in a ZIP. But with some form of README
likely bundled anyway, this isn't such a big deal.
And of course there is a security hole in placing "." on the classpath,
so it should be listed AFTER all the dependent jars (which, btw Maven's
dependency plugin can derive) else you could have trojan classes being
loaded ahead of intended ones.

So my 2 cents is to actually AVOID the uber-jar solution where possible,
but DO supply all the code required by your application



------------------------------------

[Jim Tivy]

agreed



From: seajug-***@public.gmane.org [mailto:seajug-***@public.gmane.org] On Behalf Of
Stuart Maclean
Sent: October-25-13 5:03 PM
To: seajug-***@public.gmane.org
Subject: [seajug] Re: one jar to rule them all





A nice read, but note that someone commented on the tricky part of
packaging content from many jars into one uber-jar. For instance, what
about duplicated resource names??

I have found a nice middle ground. In the 'main' jar, you define in its
Manifest a class-path variable which lists the other, dependent jars.
These then have to be found in the same dir as the initial main jar was
located. I can then add "." to this class-path variable. This allows me
to 'extract' any config files that are located by their loader code
using the classpath. log4j springs to mind, it wants to load its
log4j.properties file from the classpath, which, if you have a monster
uber-jar, means burying that prop file in the jar. Having it on the
filesystem but still loadable via the classpath means you can tell your
'user' to 'edit the log4j.properties file in the directory where all the
jars are, replacing any log level with th word DEBUG'. OK, that's a
stretch but at least it doesn't involve unbundling the uber-jar, editing
the log4.properties file and re-bundling it all back up.

The flip side of the 'many jars + config files' is of course that they
all need packaging up, probably in a ZIP. But with some form of README
likely bundled anyway, this isn't such a big deal.
And of course there is a security hole in placing "." on the classpath,
so it should be listed AFTER all the dependent jars (which, btw Maven's
dependency plugin can derive) else you could have trojan classes being
loaded ahead of intended ones.

So my 2 cents is to actually AVOID the uber-jar solution where possible,
but DO supply all the code required by your application

[Paulo Avelar]

I have been using maven shade for quite a while, and I really like it.
You can configure it to exclude duplicate resources, etc.
I recommend that you first make sure your pom dependency graph is pretty
clean, that is, no multiple versions of libraries due to transitive
dependencies.
You can clean it, using proper maven <excludes> tags.
My favorite way to find out duplicate dependencies in maven is to use
Intellij's maven dependency graph visualizer. (but you can simply use
mavenmvn dependency:tree) command.
If you don't have a "clean" pom, the shade plugin will report lots of
duplicate warnings.

Hope this helps,

Have fun,
Paulo Avelar

Post by Nimret Sandhu
fyi for those interested in learning more about the maven shade plugin or
the fun to be had when creating a command line app which needs to do funky
classpath fun to accomodate conflicting dependencies ala automatic
http://www.javacodegeeks.com/2013/01/one-jar-to-rule-them-all.html
fun read :)
-
Nimret Sandhu
http://www.nimret.org