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 >
