Go for it Kay-Kay. Its an old contribution by Ning Li. If you do move it, we can remove the lucene jar at least from lib directory and perhaps a few more? There is also a pretty heavy-duty "unit test" that fires up a mini hdfs, mapreduce, and hbase cluster running mapreduce tasks and then queries all to verify stuff works. Taking that out will cut build test times in half (smile).
St.Ack On Thu, Feb 4, 2010 at 10:28 PM, Kay Kay <kaykay.uni...@gmail.com> wrote: > On 02/04/2010 06:32 PM, Stack wrote: >> >> On Thu, Feb 4, 2010 at 6:24 PM, Lars Francke<lars.fran...@gmail.com> >> wrote: >> >>> >>> I've just seen your comment on HBASE-1402. It'll be no problem to keep >>> the two different API versions in the core. I'll just use two >>> different package names and rewrite the ThriftServer to accept a >>> parameter to chose between the old and new API. We've already brought >>> up the old API to the new Thrift version so there shouldn't be >>> conflicts. >>> >>> >> >> Excellent. >> St.Ack >> > > While we are looking at refactoring this - there is a rudimentary lucene > indexer , available at - o.a.h.h.mapreduce.IndexTableMapper/Reducer that > goes through a given table and column names and creates an index. While I > can definitely how valuable this is- I do not see this as core to hbase > functionality but rather distracting. I can volunteer to move this to github > with appropriate documentation and artifacts published to mvn central , but > am curious to know the thoughts of the people and possible stakeholders in > this list to know the opinions. Thanks. > > > > >
