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 <[email protected]> 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 <[email protected]> > 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. >
