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.
