I think we only need to depend on hbase-client for hbase-rest and hbase-thrift? No?
Sean Busbey <[email protected]> 于2020年4月28日周二 下午1:44写道： > Can't we adjust the REST server to not need YARN? > > On Mon, Apr 27, 2020 at 5:21 PM Josh Elser <[email protected]> wrote: > > > I'd think we'd want to approach that the other way around. Shade what > > Jersey we need for REST, and (continue to) let Hadoop run wild. > > > > Locking ourselves to specific upstream YARN jars worries me. > > > > On 4/27/20 5:05 PM, Nick Dimiduk wrote: > > > 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 <[email protected]> wrote: > > > > > >> > > >> > > >> On 4/27/20 1:52 PM, Nick Dimiduk wrote: > > >>> On Mon, Apr 27, 2020 at 10:11 Stack<[email protected]> wrote: > > >>> > > >>>> On Mon, Apr 27, 2020 at 9:44 AM Josh Elser<[email protected]> > 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. > > >> > > > > > >
