hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: [DISCUSS] More Shading
Date Sun, 02 Oct 2016 05:21:58 GMT
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