Hi Hari, The term contrib module usually refers modules that reside under a specially designated folder - usually called contrib, which is not generally built and their testing is not considered part of the testing of the main project. Based on your clarification, I do not think this is what you are proposing.
I believe that part of what you are proposing is to drop the "flume-ng-" prefix from module folders. I support doing this as it is redundant and adds to the path lengths. It should be applied recursively so that flume-ng-sinks/flume-hdfs-sink should be shortened to sinks/hdfs etc. Regarding checking in the RegexHbaseEventSerializer, I feel it is not out of place within the sink given that it will be generally handy for users. If you do feel like separating this out into a separate module it could be under sinks/hbase-serializers/regex. Regards, Arvind Prabhakar On Sun, Jun 17, 2012 at 2:38 PM, Mubarak Seyed <[email protected]> wrote: > +1 > > Recently HBase project has been converted (source tree into Maven modules) > using HBASE-4336 > > We can modularize something like > > + core > + sources > + sinks > + examples > + tools > + assembly > > Thanks. > -Mubarak > > > > > On Jun 17, 2012, at 1:49 AM, Hari Shreedharan <[email protected]> > wrote: > > > Just to clarify - this code should still be built and bundled with Flume. > > What I am proposing is to reorganize the code, so that they are in > separate > > modules - thus in different folders. These contributions should still be > of > > the same quality we expect and also be built in the main flume build. > > > > Thanks > > Hari > > > > On Sat, Jun 16, 2012 at 6:32 PM, Hari Shreedharan < > [email protected] > >> wrote: > > > >> Hi Flume devs, > >> > >> I would like to propose moving several pieces of code out to a different > >> contrib module which are pieces of code not essential to flume > >> functionality but pluggable into some Flume framework. Examples of this > are > >> the various kinds of interceptors, event serializers etc. I don't think > we > >> should keep them in the code tree as the interceptor framework or the > >> HBase/HDFS sinks - as this adds several files into the main module. When > >> recently a new serializer was being contributed for the HbaseSink, I > really > >> wanted it checked in, and I checked it into the main module - since I > >> didn't know where else it should go. It didn't make much sense to > create a > >> new package either. > >> > >> It is really great that people are implementing features and > contributing > >> it back to Flume. This is an example of Flume maturing as a project. As > a > >> result, we need to define a place where such contributions go. We could > >> keep them in the same package to prevent bc issues, but move them out to > >> another module. > >> > >> What do you guys think? > >> > >> > >> Thanks! > >> Hari > >> > >
