Ok, I was able to work around the issues that I was having downstream. We'll revisit this if it causes more problems in the future.
On Thu, Nov 2, 2017 at 6:13 PM, Mike Drob <[email protected]> wrote: > 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 <[email protected]> wrote: > >> On Wed, Nov 1, 2017 at 10:58 AM, Mike Drob <[email protected]> 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 >> > >
