hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Decision/Discussion about HBASE-2170: Lightweight client/Refactoring of source tree
Date Mon, 17 May 2010 18:28:31 GMT
On Fri, May 14, 2010 at 3:00 PM, Al Lias <al.lias@gmx.de> wrote:
> oh I was not in the trunk and haven't seen the modules...

Yeah, trunk has modules but I'm thinking we should get rid of them.

My reasoning is that we've just undone all contribs.  They've all been
moved out to github or folded back up into core.  Now we are mavenized
its easy (enough) for dependent projects pulling in the latest hbase
build.   If no contribs, there is no need for an involved mvn build we
currently have with submodules of core, contrib, etc., so we should be
able to move to a cleaner, flat mvn model where there are no
submodules and the mvn product is a single hbase.jar.

> 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).

So, if no modules, could we still produce an hbase-client via
something like an assembly or, given that it would need a supporting
pom, we could only do it if we keep up modules?

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

This seems easy to do in mvn.  The resultant jar though would be enormous.


> 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" ...

View raw message