git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[DISCUSS] including shaded artifacts in the convenience binary


Hi folks!

Over in HBASE-20331 I'm trying to polish up our story around how
downstreamers make use of our shaded artifacts. As a part of that I'd
like have them present as a part of a "normal" hbase installation.

Previously when we've discussed this topic, the assumption was
downstream folks would package up the shaded client with their
application themselves. Presumably this would be done via maven or the
like.

Having worked with them for awhile, I think we're better off including
them after all.

1) If most applications are going to use the shaded clients, then by
not shipping them we're encouraging a situation where you end up with
a copy per application.

2) If we ship them we can simplify the default path for some uses,
namely making hbase mapredcp return the shaded mapreduce client.
Similarly, we could make a "client classpath" command that gave the
shaded artifact as an alternative to the current bloat in the hbase
classpath

3) If we ship them we can update the docs that walk through using the
example mapreduce tools to make use of the shaded mapreduce client. If
we don't make that update we'll essentially have docs that say "here's
how you run _our_ MR jobs that talk to HBase, but you shouldn't do
that when running _yours_", which is confusing.

I have a POC patch for just adding them up on HBASE-20615. It keeps
them out of the normal server classpath entirely.

An alternative is that I could help Josh finish up HBASE-19735 "create
a minimal client tarball" and we could start pushing folks to install
it on nodes that they expect to use for connecting to hbase. (I'd want
to bring it back into 2.1 in that case.)

What do folks think?