[jira] [Commented] (HBASE-4336) Convert source tree into maven modules

["Jesse Yates (Commented) (JIRA)" <ji...@apache.org>]

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

Jesse Yates commented on HBASE-4336:
------------------------------------

So working through some of the packages, there are a lot of dependencies between files for things like constants or static methods. Moving the whole file into the shared directory for just these couple of things seems excessive (why should the client need to know about the hfile?). 

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

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.

Thoughts?

If no one disagrees, I'll precede with the described methodology in (1) and (2).
                
> 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