Mike Percy 2012-08-14, 09:38
Brock Noland 2012-08-14, 10:40
Jarek Jarcec Cecho 2012-08-14, 10:49
Ralph Goers 2012-08-14, 16:14
Will McQueen 2012-08-14, 16:47
Ralph Goers 2012-08-14, 17:25
Ralph Goers 2012-08-14, 17:29
Patrick Wendell 2012-08-14, 19:38
-Re: [DISCUSS] Annotating interface scope/stability in Flume
Mike Percy 2012-08-15, 07:20
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.
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
> >> path to denote packages (public or otherwise) that are not intended to
> >> used as a public API:
> >> "All packages that are part of the platform implementation but contain
> >> API that should be exposed to ISVs are considered internal
> >> packages. All implementation packages should be flagged as internal,
> >> the tag occurring just after the major package name. ISVs will be told
> >> all packages marked internal are out of bounds. (A simple text search
> >> ".internal." detects suspicious reference in source files; likewise,
> >> "/internal/" is suspicious in .class files). "
> > FWIW, I also think this is a good idea.
> >> [Ref:
> >> 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
Brock Noland 2012-08-15, 07:28
Brock Noland 2012-08-15, 07:30
Arun C Murthy 2012-08-15, 07:29
Arun C Murthy 2012-08-14, 17:15