Yeah, it sounds reasonable to me to use a subset of the same annotations that Hadoop uses, such as @Public and @Private.
As far as using ".internal." package names to denote non-public classes, that works for new classes but I don't think it really works for existing classes, which makes adopting it harder. Regards, Mike On Tue, Aug 14, 2012 at 12:38 PM, Patrick Wendell <[email protected]>wrote: > We definitely need something like this, given that extensability is > the expectation in Flume (not the exception). > > It's likely that the flume developer community will overlap with > Hadoop developer community, so using a subset of the Hadoop > annotations makes sense. @Private and @Public seem like a good fit for > what we need right now. > > - Patrick > > On Tue, Aug 14, 2012 at 10:29 AM, Ralph Goers > <[email protected]> wrote: > > > > On Aug 14, 2012, at 9:47 AM, Will McQueen wrote: > > > >> Something to consider: Eclipse uses the string 'internal' in their > package > >> path to denote packages (public or otherwise) that are not intended to > be > >> used as a public API: > >> > >> "All packages that are part of the platform implementation but contain > no > >> API that should be exposed to ISVs are considered internal > implementation > >> packages. All implementation packages should be flagged as internal, > with > >> the tag occurring just after the major package name. ISVs will be told > that > >> all packages marked internal are out of bounds. (A simple text search > for > >> ".internal." detects suspicious reference in source files; likewise, > >> "/internal/" is suspicious in .class files). " > > > > FWIW, I also think this is a good idea. > > > > > >> [Ref: > >> > http://wiki.eclipse.org/Naming_Conventions#Internal_Implementation_Packages > ] > >> > >> Here are some additional links on evolving Java APIs: > >> http://wiki.eclipse.org/Evolving_Java-based_APIs > >> http://wiki.eclipse.org/Evolving_Java-based_APIs_2 > >> http://wiki.eclipse.org/Evolving_Java-based_APIs_3 > >> > >>>> Flume configuration is actually pretty brittle > >> FLUME-1051 might address this concern. > >> > > I'm not sure how. That issues seems more about guaranteeing validity > than making the configuration provider more flexible. > > > > > > Ralph > > >
