Shaded Artifacts (Uber-jars) - Lessons learnt.

by IN3K8 Solutions on Tuesday, May 3, 2011 at 3:13pm ·

I would like to reflect on the problems we experienced in the past week in our use of shaded artifacts - the uber-jar as it has also come to be known. The uber-jar allows you to make a single package for code and it's dependencies. It provides the capability for code publishers to distribute their code with all dependencies in a single package. It's major strength comes from it's use of a well understood deployment mechanism - the simple jar. It also derives from strength from the availability of tooling support in the form of a Maven plugin - the maven-shade-plugin.

 

 

Last week we came up against a major failing of this mode of packaging - class path hell. We had unwittingly added an uber-jar as a dependency in another project. This project also had a number of other dependencies which clashed. It was fine when we ran the code against an application server like Jetty but gave us severe issues when we deployed the same code to Weblogic. This was mainly because the Weblogic container ( version 9.2) already had some of these classes in its class path and was less tolerant - another post for another day. It took sometime to discover that our source of pain was the uber-jar.

 

 

Our solution was to make two jars for the dependency one in it's uber-jar or shaded form and the other was the vanilla jar sans dependencies. The vanilla jar now became the default version that dependent projects would use. For standalone deployments, the shaded version becomes the preferred candidate. This fixed our problem and helped sanitise the class path also. It also meant that we could deploy both artifacts to our binary repository individually.

 

 

I believe that the two jar solution should be the default solution and should be encouraged by the tooling. If we had done this from the get go, we'd have had a smoother ride during the deployment phase. I also believe that uber-jars should be used sparingly but that a zip file which contains the core jar and its dependencies as individual jars within the zip file is preferable, especially as it is transparent.

 

 

I look forward to hearing your thoughts.


· Comment · Share