Any other feedback here folks? Mike D, you leaning towards the client tarball or just making sure I've considered it?
(FWIW, I think the client tarball would work fine practically speaking and don't feel strongly about either approach.) On Thu, May 24, 2018 at 1:01 AM, Sean Busbey <bus...@apache.org> wrote: > 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?