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. >
