Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase, mail # dev - modularizing trunk


Copy link to this message
-
Re: modularizing trunk
Matt Corgan 2012-05-09, 18:18
I talked briefly with Jesse about this before, but thought it was worth
bringing up one more time.  I'm worried that the name hbase-core is a bad
choice for this first module that contains all the code.

As soon as the modules are created, I'm planning to submit
HBASE-4676<https://issues.apache.org/jira/browse/HBASE-4676>as a
separate module (hbase-prefix-trie) that has a dependency on just a
handful of existing classes (KeyValue, the DataBlockEncoder interface,
Bytes, and maybe a couple others).  My idea was to pull those critical
classes into a small central module that contains the fundamental classes
of HBase and has no (or few) external dependencies.  If the initial module
is called hbase-core, then the new shared module would have to be called
hbase-common.  I'm worried that having an hbase-common and an hbase-core
will cause needless confusion for years to come.

I'd suggest calling this first module hbase-server since the majority of
the classes are related to the master and regionservers.  Then we can pull
out the fundamental classes (KeyValue, Bytes, etc) into a small module
called hbase-core.  After that, we can create an hbase-client module that
only depends on hbase-core (so few or no dependencies).  My main point
being that we'll want to reserve the name hbase-core for the actual core
classes and not throw everything in there.

Another option is to treat the current code base as hbase-core (the current
plan), and pull 95% of the classes out to another module called
hbase-server.  But, it seems like it would be easier to extract the smaller
number of core classes out to a new module.  That is only a theory
though... maybe others who've tried to refactor in the past know better.

Anyway, just thought I'd throw that out there since the module naming
discussion in the jira got really confusing.  Last thing I want to do is
sidetrack Jesse's progress...

Matt
On Wed, May 9, 2012 at 10:43 AM, Stack <[EMAIL PROTECTED]> wrote:

> Sounds good Jesse.
>
> @Ted
>
> > w.r.t. timing of integration of HBASE-4336, we should plan in advance.
>
> Yes.  Thats what Jesse has been doing (See the issue for a recounting
> of prep that has gotten us to here).
>
> > 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
> > HBASE-4336.
>
> Read Jesse's prescription above.  HBASE-5732 will be in before May
> 22nd so that one in particular is a non-issue.
>
> > 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.
> >
>
> Disagree.  On 23rd there will be a bunch of contributors all in the
> one room.  We'll be able to address issues and educate in person.
>
> St.Ack
>