hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anoop John <anoop.hb...@gmail.com>
Subject Re: [DISCUSS] More Shading
Date Sun, 02 Oct 2016 02:34:03 GMT
Thanks for the details Stack.  Ya I feel Sean's idea would give the devs
the cleanest way. The shaded (possibly patched 3rd party libs) available in
our related repo.  I like it.

The shaded client and server artifacts is giving a single fat jar right?
This includes hbase stuff+ all 3rd parties shaded. That can co exists may
be. Need change in their build steps may be. If we shade all of
dependencies into our related repo, this might not be much diff from the
shaded client/server stuff then.

Anoop


On Sunday, October 2, 2016, 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?
> It doesn't seem so.  These modules are supposed to shade HBase and
upstream
> from downstream users.
> The proposed shades and protects hbase, but upstream dependencies can
still
> leak into downstream?
>
> 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