hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ramkrishna vasudevan <ramkrishna.s.vasude...@gmail.com>
Subject Re: [DISCUSS] More Shading
Date Mon, 03 Oct 2016 05:29:58 GMT
+1 for Sean's ideas. Bundling all the dependent libraries and shading them
into one jar and HBase referring to it makes sense and should avoid some of
the pain in terms of IDE usage. Stack's doc clearly talks about the IDE
issues that we may get after this protobuf shading goes in. It may be
difficult for new comers and those who don't know this background of why it
has to be like that.

Regards
Ram

On Sun, Oct 2, 2016 at 10:51 AM, Stack <stack@duboce.net> wrote:

> On Sat, Oct 1, 2016 at 6:32 PM, Jerry He <jerryjch@gmail.com> wrote:
>
> > How is the proposed going to impact the existing shaded-client and
> > shaded-server modules, making them unnecessary and go away?
> >
>
> No. We still need the blanket shading of hbase client and server.
>
> This effort is about our internals. We have a mess of other components all
> up inside us such as HDFS, etc., each with their own sets of dependencies
> many of which we have in common. This project t is about making it so we
> can upgrade at a rate independent of when our upstreamers choose to change.
>
>
> > It doesn't seem so.  These modules are supposed to shade HBase and
> upstream
> > from downstream users.
> >
>
> Agree.
>
> Thanks for drawing out the difference between these two shading efforts,
>
> St.Ack
>
>
>
> > Thanks.
> >
> > Jerry
> >
> > On Sat, Oct 1, 2016 at 2:33 PM, Andrew Purtell <andrew.purtell@gmail.com
> >
> > wrote:
> >
> > > > Sean has suggested a pre-build step where in another repo we'd make
> > hbase
> > > > shaded versions of critical libs, 'release' them (votes, etc.) and
> then
> > > > have core depend on these. It be a bunch of work but would make the
> > dev's
> > > > life easier.
> > >
> > > So when we make changes that require updates to and rebuild of the
> > > supporting libraries, as a developer I would make local changes,
> install
> > a
> > > snapshot of that into the local maven cache, then point the HBase build
> > at
> > > the snapshot, then do the other half of the work, then push up to both?
> > >
> > > I think this could work.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message