That's there for Flume 0.9 backwards compatibility, thus being in legacy sources. It's already marked as @deprecated.
Someone who is an expert with Thrift may have more insight into whether we can maintain backwards compat while changing the package/class names, but my understanding is that it was left that way for that reason. On Tue, Dec 4, 2012 at 9:12 AM, Brock Noland <br...@cloudera.com> wrote: > Hi, > > It looks like it's from the legacy thrift source: > > > https://github.com/apache/flume/tree/trunk/flume-ng-legacy-sources/flume-thrift-source/src/main/java > > Does anything know if there is a valid reason it's not org.apache? I > assume it was just missed. > > Brock > > On Tue, Dec 4, 2012 at 11:09 AM, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > > > > On Dec 4, 2012, at 8:16 AM, Brock Noland wrote: > > > >> Hi, > >> > >> I assume the PDFs and API Docs on the release page > >> http://flume.apache.org/releases/1.3.0.html are just manually > >> generated and then committed directly to the prod website? > > > > Yes - it looks like you did it correctly. Unfortunately, the > maven-pdf-plugin doesn't support RST so you have to do it manually. > > > > I noticed the API Javadoc contains a reference to > com.cloudera.flume.handlers.thrift. Why is that? > > > > Ralph > > > > > >> > >> I just want to confirm as I am trying to put together a guide on how > >> to edit the website and what items need to be updated as part of a > >> release. > >> > >> Brock > > > > > > -- > Apache MRUnit - Unit testing MapReduce - > http://incubator.apache.org/mrunit/ >
