Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Flume >> mail # dev >> [DISCUSS] Annotating interface scope/stability in Flume

Copy link to this message
Re: [DISCUSS] Annotating interface scope/stability in Flume
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
> 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