Mike from another thread asked about shading jackson into hbase-thirdparty. That reminded me of a question I was thinking recently, in conjunction with HBASE-18800 "[Propaganda] Push shaded hbase-client as gateway to an hbase cluster going forward".
We have shaded artifacts in hbase-thirdparty (hbase-shaded-miscellaneous, hbase-shaded-protobuf and hbase-shaded-netty). The purpose is to shade and bundle the jars with versions hbase uses internally. Then in hbase-shaded-client we do shading again for some of the same jars, but they are more non-hbase, transitive dependencies. For example, in hbase-shaded-miscellaneous, we shade guava 22. But hbase-client will bring in guava 11 from hadoop-common. In hbase-shaded-protobuf, we shade protobuf 3. But hadoop brings in protobuf 2.5. We will be doing shading of all these in hbase-shaded-client (and the hbase-shaded-mapreduce), with the same relocation (org.apache.hadoop.hbase.shaded). The end result is shaded guava 22 or guava 11? Protobuf 3 or protobuf 2.5? I checked hbase-shaded-client and found it had the shaded guava 22 classes. Looks like the shading process will only add one version of the classes with the same name. This will potentially have problem, and potentially make it unusable in unlucky situations. I bring it up here for awareness and discussion. First, is this really a problem? Second, how to fix it? Maybe a different relocation offset in hbase-thirdparty? Thanks, Jerry
