[
https://issues.apache.org/jira/browse/HBASE-5976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273752#comment-13273752
]
Matt Corgan commented on HBASE-5976:
------------------------------------
{quote}@Matt: why the disposition to pulling up rather than pushing down?{quote}
My assumption is that given 2 modules, hbase-common and hbase-cluster, we would
configure it so that hbase-cluster can "see" hbase-common (hbase-common is in
hbase-cluster's classpath), but NOT vice versa. Were you also assuming that?
I think that's by far the most important part of the whole modularization
effort.
In that case, it is relatively easy to pull a class like KeyValue up from
hbase-cluster to hbase-common because it has few dependencies. For example, to
pull KeyValue up, we'd need to bring these classes/jars along with it:
hadoop-core.jar, commons-logging.jar, guava.jar, HeapSize.java, ClassSize.java,
and Bytes.java. So that's pretty easy.
If later I go on to make an hbase-prefix-trie, or hbase-codec, or
hbase-whatever module. I let this new module see hbase-common, but not
hbase-cluster. For hbase-prefix-trie, I will need access to 2 more classes:
DataBlockEncoder and DataBlockEncoding, so i just pull those up in to
hbase-common and I'm done. It'll be important that hbase-prefix-trie cannot
see into hbase-cluster and hbase-cluster cannot see into hbase-prefix-trie,
because that is how hairballs happen. In this case the two modules will
communicate with each other through the DataBlockEncoder interface in
hbase-common, and the DataBlockEncoder implementation is instantiated via
reflection at runtime.
If someone goes on to make hbase-client, they will need to pull a few more
interfaces up into hbase-common. And maybe in this case hbase-cluster can see
into the simpler hbase-client module (but we don't want hbase-client seeing
into hbase-cluster).
If we go with a push-down methodology, i'm not sure where you'd start. You
would need to push down some big implementation classes that have circular
dependencies on other classes, so you'd have to push down the dependencies as
well, which will lead to more dependencies and so on. And if you pull out an
implementation class, you need to push-down all the tests that reference it. I
suspect it would spiral out of control until you've pushed down just about
everything except KeyValue.
> 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
