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
