hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Yates <jesse.k.ya...@gmail.com>
Subject Re: modularizing trunk
Date Wed, 09 May 2012 20:27:05 GMT
I was worried this discussion around naming might happen. Should I open a
sub-jira on 4336 for how to name the modules, what future modules should
be, etc.?

-Jesse
-------------------
Jesse Yates
@jesse_yates
jyates.github.com


On Wed, May 9, 2012 at 12:06 PM, Andrew Purtell <apurtell@apache.org> wrote:

> On Wed, May 9, 2012 at 12:01 PM, Stack <stack@duboce.net> wrote:
> > On Wed, May 9, 2012 at 11:18 AM, Matt Corgan <mcorgan@hotpads.com>
> wrote:
> >> I'd suggest calling this first module hbase-server since the majority of
> >> the classes are related to the master and regionservers.  Then we can
> pull
> >> out the fundamental classes (KeyValue, Bytes, etc) into a small module
> >> called hbase-core.  After that, we can create an hbase-client module
> that
> >> only depends on hbase-core (so few or no dependencies).  My main point
> >> being that we'll want to reserve the name hbase-core for the actual core
> >> classes and not throw everything in there.
> >>
> >
> > We don't want hbase-common and then hbase-core for sure.
> >
> > The first module rightly should be called hbase-bucket since its just
> > a holding module while we do our sort-through.  Can we figure a name
> > that better conveys the module as so?  hbase-hbase?  hbase-bucket?
> > hbase-99%? hbase-pick-u-part?   hbase-residuum?
>
> hbase-server is as reasonable as any, right?
>
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet
> Hein (via Tom White)
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message