hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <els...@apache.org>
Subject Re: [DISCUSS] Interest in "client" and "server" tarballs?
Date Fri, 05 Jan 2018 17:37:55 GMT
On 1/5/18 10:43 AM, Stack wrote:
> On Thu, Jan 4, 2018 at 2:50 PM, Josh Elser <elserj@apache.org> wrote:
> 
>> Had an ask from some $dayjobs folks to split up the "monolithic" hbase
>> binary tarball that we generate in the build into two pieces:
>>
>> 1. A minimal installation which would only contain things that "normal
>> users" would need.
>> 2. A server-side installation which would not contain things only used by
>> clients (in reality, I think this would be essentially the same as our
>> current tarball).
>>
>> This would be pretty simple to do in >=2.0.0 with some extra assembly
>> descriptors (with some of the extra break-out of classes previously in
>> hbase-server), but I wasn't sure what kind of interest other folks would
>> have. Obviously, I would only want to suggest such a change if there was
>> buy-in from everyone else; otherwise, it will just cause fragmentation in
>> the project. It's something easily (I think) achievable outside of the
>> standard build process, so it's not something super-critical to be
>> maintained upstream.
>>
>> Any thoughts?
>>
>>
> We've been working toward this goal w/ a good while now (Appy's untangling
> mapreduce and zookeeper breaking them out as distinct modules, Duo making
> client depend on basic, read-only usage of zk, the CP refactoring project,
> and so on).
> 
> An assembly that did an hbase-client tgz is probably not far off (Might
> require some more messing untangling dependency knots and tangles...). As
> per Drob, it would be good to foreground our shaded access artifacts.
> 
> Thanks Josh,
> S

Superb. Sounds like we're on the same page that something here would be 
aligned with the long-term vision. I'll try to see what I can whip up 
and we can iterate on that.

Thanks all.

Mime
View raw message