hbase-issues mailing list archives

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

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

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

@stack
{quote}
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.
{quote}

I've tried a couple of free options out there, but nothing was able to really scale to handle
the hbase code.  I'd love to try using restructure101 to dig through this.

{quote}
and then the Util class would be hoisted up into the packages above so it could be used from
multiple packages
{quote}

The utils would be hoisted into the 'shared' module, so we can avoid having dependencies between
things like the client and server modules. This means that shared gets heavily cross-referenced,
but that complexity is bound to a single location, rather than being tied all over the place
(like it is now, smile).

{quote}
I'm not a fan of building up HConstants to be this fat Interface refereneced by all and sundry
{quote}

My logic here is the same as the previous - trying to reduce the interpackage/module complexity
by hoisting out common elements. I agree that things that are just used _within_ a class should
remain with that class (as private members), but when you start getting things across packages
making references to this file, it gets *really* hard to keep track of which constants you
should be using where. For instance, the craziness I found with the DEFAULT_BLOCK_SIZE, even
though that has apparently been removed, its indicative of the bigger problem. 

Instead, for things like this, it is really nice to have a single place to go to find the
right constant. Doing something like HConstants.HFile.DEFAULT_BLOCK_SIZE actually feels really
clean when done from within an IDE. HConstants is already a pretty massive file, and the efforts
to keep constants in their respective classes has only lead to more pain (And probably some
duplication), rather than making it easier and cleaner. 

{quote}
An org.apache.hadoop.hbase.constants
{quote}

Yeah, that was the idea. It would help break the constants into a couple different files,
but at the same time keep them more together. Problem here is that you will likely end up
having do an inline full path specification of the class to differentiate it from the actual
class, where you are probably using it, (eg. org.apache.hadoop.hbase.constants.HFile.DEFAULT_BLOCK_SIZE),
which is annoying.   
                
> 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