[
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 tested.
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 are:
> * 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
