hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Corgan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5976) Initial module naming
Date Thu, 10 May 2012 18:50:48 GMT

    [ https://issues.apache.org/jira/browse/HBASE-5976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13272635#comment-13272635

Matt Corgan commented on HBASE-5976:

{quote}I think its going to be harder than we think to pull server classes out{quote}
Trying to understand what you mean here Jesse.  I think i would agree with that statement,
so I was suggesting pulling things like KeyValue, Bytes, from hbase-server up to hbase-common.

The key benefit of the modules is to restrict the dependencies between modules with the goal
of preventing big hairballs.  It's very similar to the motivation for interfaces and public/private/protected
scopes in java - tools for strongly enforcing that classes don't directly depend on things
they shouldn't.

To think a little further down the line: after pulling "up" common classes like KeyValue,
we could then pull "up" an hbase-memstore module that depended on hbase-common but could not
see what is going on down in hbase-server.  Then pull "up" an hbase-wal module.  Then hbase-region.
 When we pull up these modules, we try to bring their unit tests up with them (unit tests
that don't need a whole cluster).

Every time we pull one of these modules and its tests "up" out of hbase-server, it shrinks
and simplifies the code in the hbase-server module.  Just as importantly, it also reduces
the quantity of tests in hbase-server because modules like hbase-common, hbase-memstore, and
hbase-wal each have unit tests that prove their correctness, so they can be treated like black
boxes by hbase-server.  Just like the current project assumes that Guava classes are already
well tested, the hbase-server module could now assume that the memstore internals are well

Just food for thought since we still have a couple weeks to discuss =).  We used a pulling
"up" methodology at HotPads a few years back and it's worked really well for us.  Starting
with a single "site" project, we first pulled up static utils, then services, then pulled
out a complex indexing data-structure, etc, etc
> Initial module naming
> ---------------------
>                 Key: HBASE-5976
>                 URL: https://issues.apache.org/jira/browse/HBASE-5976
>             Project: HBase
>          Issue Type: Brainstorming
>          Components: build
>    Affects Versions: 0.96.0
>            Reporter: Jesse Yates
>   Original Estimate: 336h
>  Remaining Estimate: 336h
> There is currently a lot of discussion around the 'right' name for the initial module
that will host all the code in the primary modularization of hbase. The current contenders
> * hbase-core
> * hbase-common
> * hbase-server
> * hbase-bucket
> * hbase-hbase
> Let's duke it out and pick the best, while keeping in mind that this module will *not*
remain the sole module going forward, but is merely the precursor 
> Timeline to close this issue is the day before the code gets committed.
> Source: http://search-hadoop.com/m/pwi1t1e9K0R/modularizing+trunk&subj=modularizing+trunk

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message