hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Kay <kaykay.uni...@gmail.com>
Subject Re: Discussion: Move contribs out of hbase?
Date Fri, 05 Feb 2010 07:01:18 GMT
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.unique@gmail.com>  wrote:
>    
>> On 02/04/2010 06:32 PM, Stack wrote:
>>      
>>> On Thu, Feb 4, 2010 at 6:24 PM, Lars Francke<lars.francke@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.
>>
>>
>>
>>
>>
>>      


Mime
View raw message