hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-4336) Convert source tree into maven modules
Date Fri, 03 Feb 2012 06:23:53 GMT

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

stack commented on HBASE-4336:
------------------------------

@Jesse For this kind of work I'd suggest something like restructure101.  They are a good crew
and have given apache hbase a license; I could ask them for one for you.  Using restructure101,
you can see our tangled mess in a pretty diagram.... Then you can try out various refactorings
w/o actually changing code to see how viable a refactor.  If you want to check it out, come
by and we'll sit around a screen for an hour.

On your suggestions:

{code}
I'm proposing to follow two general ideas to resolve this:
1) Abstracting out the static methods into a Util class of the same name (so it would be something
like HLogUtils for static method in HLog).
{code}

... and then the Util class would be hoisted up into the packages above so it could be used
from multiple packages?  Master and Regionserver packages need to know about hlog?  Should
we refactor hlog to its own package?  Is that any better?  Lots of tools rate complexity by
how much interpackage dependency we have going on (I suppose we could have an hlog module
in an org.hbase.wal package that the regionserver and master modules depend on but yeah, we'd
have a million modules then).

{code} 
2) Moving super general constants to HConstants (like HFile.DEFAULT_BLOCK_SIZE, which is scattered
liberally throughout) and then more specific constants to subclasses within HConstants, meaning
you might get something like HConstants.HLog.SPLIT_SKIP_ERRORS_DEFAULT.
{code}

I'm not a fan of building up HConstants to be this fat Interface refereneced by all and sundry.
 I'd think that an HFile.DEFAULT_BLOCK_SIZE belongs in HFile.  Whats odd is that there are
refernces to this constant outside of hfile.  Why they reference it?

{code}
My other idea for (2) was to have a constants package that just has the constants for each
class. This second means smaller files, but less easy/immediate/natural access to the constants,
but gives you nice separation between the constants.
{code}

An org.apache.hadoop.hbase.constants?
                
> Convert source tree into maven modules
> --------------------------------------
>
>                 Key: HBASE-4336
>                 URL: https://issues.apache.org/jira/browse/HBASE-4336
>             Project: HBase
>          Issue Type: Task
>          Components: build
>            Reporter: Gary Helmling
>            Priority: Critical
>             Fix For: 0.94.0
>
>
> When we originally converted the build to maven we had a single "core" module defined,
but later reverted this to a module-less build for the sake of simplicity.
> It now looks like it's time to re-address this, as we have an actual need for modules
to:
> * provide a trimmed down "client" library that applications can make use of
> * more cleanly support building against different versions of Hadoop, in place of some
of the reflection machinations currently required
> * incorporate the secure RPC engine that depends on some secure Hadoop classes
> I propose we start simply by refactoring into two initial modules:
> * core - common classes and utilities, and client-side code and interfaces
> * server - master and region server implementations and supporting code
> This would also lay the groundwork for incorporating the HBase security features that
have been developed.  Once the module structure is in place, security-related features could
then be incorporated into a third module -- "security" -- after normal review and approval.
 The security module could then depend on secure Hadoop, without modifying the dependencies
of the rest of the HBase code.

--
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

        

Mime
View raw message