On 02/04/2010 10:47 PM, Stack wrote:
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?
Definitely we can remove lucene from the ivy list of dependencies and
hence from the classpath , making it leaner.
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).
Will look into this, as well.
I was thinking of github for hosting and eventually publishing artifacts
to central maven repository, through nexus sonatype, so that integrating
should be easy.
That brings back to the original question on HBASE-1933 , to motivate to
get started independently.
As far as thrift is concerned, I believe we can take the option of
publishing artifacts ourselves under - org.apache.hadoop.hbase /
libthrift artifact , for 0.2.0. zk seems wrapping up the stuff for a
3.3.0 release so if we wait for a month from here - that might become
possible too.
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.
