Ignore this comment. I guess if we are going to use the annotations there is not need to use "internal" as well.
On Wed, Aug 15, 2012 at 8:28 AM, Brock Noland <[email protected]> wrote: > Agreed it may not work for all existing classes we would like to make > internal. But it would work for things like FileChannel and MemoryChannel, > no? > > Brock > > > On Wed, Aug 15, 2012 at 8:20 AM, Mike Percy <[email protected]> wrote: > >> 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 >> > > >> > >> > > > > -- > Apache MRUnit - Unit testing MapReduce - > http://incubator.apache.org/mrunit/ > -- Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/
