hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: modularizing trunk
Date Wed, 09 May 2012 01:51:00 GMT
Thanks Jesse for the nice writeup.

w.r.t. timing of integration of HBASE-4336, we should plan in advance.
Currently there're several big patches pending checkin, e.g. HBASE-5732
(Remove the SecureRPCEngine and merge the security-related logic in the
core engine). Such patches would need rebasing if they get integrated after
On May 23, 2012, there would be quite a few patches becoming ready for

I feel HBASE-4336 should go in before (or after) 23rd so that people
working on other JIRAs have an easier time adjusting to the new structure.


On Tue, May 8, 2012 at 6:31 PM, Jesse Yates <jesse.k.yates@gmail.com> wrote:

> Hi devs,
> I'm just finishing up work on
> HBASE-4336<https://issues.apache.org/jira/browse/HBASE-4336>-
> modularization of hbase - and am planning to work with Stack to commit
> the patch to trunk. If there are no objections, the planned refactor is on
> *May
> 23, 2012 (hbase hackathon).*
> *What does this mean for you?*
> If at the commit, you don't have any patches you will just pull the latest
> version, import the projects into eclipse and move on with your life. It
> may or may not be slightly more complex to import, depending on how you are
> currently importing the project, but details on specific procedures will
> come with the commit.
> If you do have open patches, its a simple process to convert them over. You
> will export your diff into a patch file (lets assume here its the standard
> --no-prefix format). After pulling down the new version, you will just cd
> into hbase-core and apply your patch. Unless you are modifying the
> reference guide, hbase/bin scripts, hbase/conf files or the pom (please
> avoid until after the switch as we will be changing everything), then the
> patch _should_ apply cleanly. If you are modifying those files, you will
> need to split up the patch file and apply the first half from hbase and the
> second from hbase-core.
> *What is actually happening in this patch?*
> The initial plan for HBASE-4336 was to break out each of the different
> pieces of hbase into their own module. However, in practice doing the
> one-shot refactor is a huge pain and not really feasible with the current
> project velocity. Instead, 4336 sets up the framework to enable much easier
> modularization. If we want to pull out client stuff, then we merely need to
> dis-entangle the code, add a few lines to the hbase-assembly project, and
> you are off to the races (more or less - see
> HBASE-4336<https://issues.apache.org/jira/browse/HBASE-4336>for
> caveats around tests).
> After the patch goes in, we will have three modules: hbase, hbase-core,
> hbase-assemble.
>   - hbase is the parent and defines the general properties used by all the
>   children, including managing dependency versions, plugin versions and
>   general properties, and managing the docbook and site.
>   - hbase-core is where all the code will go. It will still export a
>   regular jar and a test jar and support the security profile (though
>   activation will now be -Dsecurity, rather than -Psecurity)
>   - hbase-assemble will package everything together into the final
>   tarball/rpm/deb
> In the future, packages like mapreduce, client, sever, wal, etc have been
> discussed. The means easier testing, development and deployment.
> *How can you help?
> *1) Get as much of your code into the trunk before the refactor
> 2) Take a look at https://github.com/jyates/hbase/tree/refactor-modulesand
> comment on the recent patches there (this is pretty close to what the final
> refactor will look like)
> 3) Start thinking about refactoring other modules out of hbase-core (or
> even forking on github and doing it!)
> Thanks,
> Jesse
> -------------------
> Jesse Yates
> @jesse_yates
> jyates.github.com

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message