hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <md...@apache.org>
Subject Re: [DISCUSS] shading hbase-client jackson dependency
Date Thu, 02 Nov 2017 23:13:51 GMT
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 <stack@duboce.net> wrote:

> On Wed, Nov 1, 2017 at 10:58 AM, Mike Drob <mdrob@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message