jackson-databind and anything that depends on, maybe. I think we should figure out the situation with hbase-shaded-testing-util first, then I can unwind the rest of the tree.
On Thu, Nov 2, 2017 at 5:46 PM, Stack <st...@duboce.net> wrote: > On Wed, Nov 1, 2017 at 10:58 AM, Mike Drob <md...@apache.org> wrote: > > > Hi Devs, > > > > Should have thought to discuss this sooner, but I had blinders on at the > > time and wasn't thinking about the bigger picture. > > > > Currently, hbase-client carries with it a dependency on jackson due to > our > > JsonMapper class, which is a very very thin wrapper around the jackson > > ObjectMapper. Our JsonMapper is @IA.Public > > > > Internally it is used (after a long trail of private calls) by > > MetaTableAccessor's debug logging. So even if we were able to remove > > JsonMapper, we'd still need to keep the jackson dep in hbase-client, > since > > losing this logging might be painful for somebody. > > > > Can we shade the jackson into hbase-thirdparty? I'm asking because not > > doing so is causing integration problems for me with Pig right now. I can > > certainly do exclusion magic on the pig side, but am wondering if this > > would be the more proper approach. Typically I would file some JIRAs and > > "just do it" but would like to see more consensus since 2.0 is fast > > approaching. > > > > Mike > > > > > What from jackson, which jars, would need to be in hbase-thirdparty Mr. > Drob? > S >
