hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Al Lias <al.l...@gmx.de>
Subject Re: Decision/Discussion about HBASE-2170: Lightweight client/Refactoring of source tree
Date Fri, 14 May 2010 22:00:34 GMT
oh I was not in the trunk and haven't seen the modules...

The best would certainly be a sub dir + a module "hbase-client".

If that is too much work with moving files around, you could start a
hbase-client module without any files in it, just a dumb pom.xml that
excludes everything not needed (see the attached example; projects that
include that dependency will not go for the org.eclipse.jdt dependency
for instance).

But in any case you'll have to maintain a exclusion list that will be
quite big; and many libs have to be excluded from hbase:core AND from
hadoop:core

One can also argue, why these dependencies got in initially...still I
also think it makes sense (We actually also use a stripped down jar set,
reducing client sizes by 15 Mb)

If you then look further for a one-piece-jar (for the poor without
maven), the shade plugin would do the job.

Regards

	Al

Am 14.05.2010 18:59, schrieb Lars Francke:
> Sorry. I accidentally hit "send" too soon. Damn phone keyboards.
> 
> HBase already uses sub modules. But to split this up even further we'd have
> to refactor the code which won't be easy.
> 
> So what we thought of doing is provide a second .pom for the same
> code/artifact but with a stripped down set of dependencies. There are
> multiple ways of doing this. Do you have any experience with this use-case
> and provide insight into a good solution? That'd be great as I've never done
> _this_ in particular.
> 
> Any help is appreciated.
> 
> Cheers,
> Lars
> 
> 
>>
>> On May 14, 2010 6:10 PM, "Al Lias" <al.lias@gmx.de> wrote:
>>
>> ...Maven can have submodules, ea...
> 
>>
>>> I'm sorry I must have missed your answer somehow.
>>>
>>> The problem with using 1 jar "everywhere" ...
> 


Mime
View raw message