Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
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
> >
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB