You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Stack <st...@duboce.net> on 2018/06/01 16:28:07 UTC

Re: [DISCUSS] including shaded artifacts in the convenience binary

On Tue, May 29, 2018 at 7:09 AM, Sean Busbey <bu...@apache.org> wrote:

> Any other feedback here folks?
>
>
Bundling shaded artifacts AND a client-only access tgz would be doing our
users a useful service.

Aside: Is it going to be hell to rig the build to autogenerate these new
artifacts?

S



> 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 <bu...@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?
>