On Aug 15, 2012, at 12:20 AM, Mike Percy wrote: > Yeah, it sounds reasonable to me to use a subset of the same annotations > that Hadoop uses, such as @Public and @Private. >
You guys might also want to consider the Hadoop 'Stability' notation: Stable, Evolving, Unstable. FWIW, Stability is different from Audience (Public/Private/LimitedPrivate). This is derived from Sun etc., see HADOOP-5073 for more context. Arun > 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 >>> >> -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/
