hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Dimiduk <ndimi...@apache.org>
Subject Re: DISCUSS: Move hbase-thrift and hbase-rest out of core to hbase-connectors project?
Date Mon, 27 Apr 2020 21:05:23 GMT
I suppose an alternative is to provide a shaded version of the YARN jars
needed by hbase-rest in hbase-thirdparty. We'd need these for both hadoop2
and hadoop3, to pull them in via profile, and to exclude the originals
wherever they appear as transitive deps (though they shouldn't, right?)

On Mon, Apr 27, 2020 at 11:24 AM Josh Elser <elserj@apache.org> wrote:

>
>
> On 4/27/20 1:52 PM, Nick Dimiduk wrote:
> > On Mon, Apr 27, 2020 at 10:11 Stack<stack@duboce.net>  wrote:
> >
> >> On Mon, Apr 27, 2020 at 9:44 AM Josh Elser<elserj@apache.org>  wrote:
> >>
> >>> +1 to the idea, -0 to the implied execution
> >>>
> >>> I agree hbase-connectors is a better place for REST and thrift, long
> >> term.
> >>> My concern is that I read this thread as suggesting:
> >>>
> >>> 1. Remove rest/thrift from 2.3
> >>> 1a. Proceed with 2.3.0 rc's
> >>> 2. Add rest/thrift to hbase-connectors
> >>> ...
> >>> n. Release hbase-connectors
> >>>
> >>> I'm not a fan of removing anything which was previously there until
> >>> there is are new releases and documentation to tell me how to do it.
> I'm
> >>> still trying to help dig out another project who did the 'remove and
> >>> then migrate" and left a pile of busted.
> >>>
> >>> If that's not what you were suggesting, let me shirk back into the
> >>> shadows;)
> >>>
> >>
> >> Ha ha. Not what I was suggesting but that could for sure happen.
> >>
> >> S
> >>
> >> P.S. I'm having trouble w/ REST jersey1 vs jersey2 vs Hadoop3 transitive
> >> includes++. Thrift has sporadic test failures that seem inherent to
> thrift
> >> rather of our manufacture. The discussion here was provoked by a
> daydream
> >> that bringing forward this inevitable migration of REST+thrift would
> >> 'solve' my immediate pain. Wasn't giving too much mind to the amount of
> >> work needed on the other side.
> >
> > I’m not clear on how moving the module out will resolve the class path
> > issues. Whether it’s built from the main repo or from the side repo,
> yarn’s
> > transitive hull is still present...
> >
>
> Yeah, understandable :)
>
> I think working with "something" for REST/Thrift in connectors (punt on
> H3 to start?) is reasonable. You shouldn't be stuck with the baggage of
> Jersey dependencies if that's not the problem you're trying to solve.
>

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