Depends on the definition of "covered", I think :)
I think that the shaded artifacts (client and mapreduce) would be
contained in such as tarball as described by #1, but we would also have
some more in there. A short list:
* hbase-env.sh and hbase-site.xml (or pared down versions, thereof)
* bin/hbase,hirb.rb,hbase-common.sh,hbase-config.sh
* Subset of jars and all of the ruby files in lib/
Essentially, whatever might be needed for a human who wants to interact
with HBase as a "user". Things that an administrator would need would be
in the #2 tarball.
On 1/4/18 3:54 PM, Mike Drob wrote:
Isn't the first covered by the shaded-client and shaded-mapreduce artifacts?
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?
- Josh
