The shim approach seems pretty good. We use that in Spark itself too in order to subclass or use semi-private APIs from other projects.
On Wed, Jun 1, 2016 at 4:30 PM, Mridul Muralidharan <mri...@gmail.com> wrote: > Another alternative, which is what we do internally here, is to have a shim > layer in o.a.s namespace : with everything else in our own namespace. > > The shim will act not just as a means to private api, but also as an > abstraction (in theory replaced with different version, impl, etc). > Keeping rest of o.a.b code 'clean' ... This of course assumes a reasonable > shim can be built. > > Definitely option two compared to clean separation > > Regards > Mridul > > > On Wednesday, June 1, 2016, Marcelo Vanzin <van...@apache.org> wrote: > > > On Wed, Jun 1, 2016 at 10:44 AM, Mridul Muralidharan <mri...@gmail.com > > <javascript:;>> wrote: > > > That would also depend on whether it is possible to move out of o.a.s > > > namespace - given the private[spark], etc restriction that scala > > > imposes. > > > I think Steve did allude to this in his mail. > > > > I think that should be a (reasonably) short-term goal; that would help > > with making extensions compatible with multiple Spark releases, > > something that would be harder if they depend on private-ish APIs. > > >
