On Thu, Jan 4, 2018 at 2:50 PM, Josh Elser <[email protected]> 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 > - Josh >
