hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Gray <jg...@facebook.com>
Subject RE: [DISCUSS] Change package names to org.apache.hbase
Date Fri, 28 May 2010 22:27:51 GMT
Agreed.  A lot of the o.a.h.h.client code would reference o.a.h stuff.  We wouldn't need to
keep everything, just the primary stuff like HTable, HBA, HTD/HCD, Get/Put/Delete/Scan.

> -----Original Message-----
> From: Ryan Rawson [mailto:ryanobjc@gmail.com]
> Sent: Friday, May 28, 2010 3:22 PM
> To: dev@hbase.apache.org
> Subject: Re: [DISCUSS] Change package names to org.apache.hbase
> 
> We should only have one copy of hconnectionmanager (the core of the
> client
> logic) and the old package should point to and use the new package
> under the
> covers. Few clients should depend on it.
> 
> On May 28, 2010 3:16 PM, "Jonathan Gray" <jgray@facebook.com> wrote:
> > One of the last disruptive changes that has been discussed for the
> next
> release is changing our package names from org.apache.hadoop.hbase to
> org.apache.hbase since we are now a TLP.
> >
> > I'd like to see this done, and the sooner the better. I propose we do
> it
> early next week.
> >
> > There is an existing JIRA open:
> https://issues.apache.org/jira/browse/HBASE-2484
> >
> > The questions that remain are mostly around compatibility issues with
> clients. There are also existing issues with changes to
> HColumnDescriptor
> that have broken client API compatibility.
> >
> > What I propose is to retain o.a.h.h.client and o.a.h.h.mapreduce in
> the
> next release, and mark everything in them as deprecated with links to
> o.a.h
> stuff (we may also need to retain o.a.h.h.util since that is used
> client-side as well?). We'd also copy both those packages into
> o.a.h.client/mapreduce where we'd be able to make non-backwards
> compatible
> API changes. For example, changing HColumnDescriptor to something else
> (I
> propose HFamilyDescriptor but we can deal with this separately).
> >
> > This will allow o.a.h.client to be totally cleaned out. Duplicate
> methods
> (like those jeff hammer pointed out) can be removed, method names and
> class
> names standardized, etc.
> >
> > One concern is there will be two versions of the same classes in
> different
> packages, but not sure of another way around it. Changing all the class
> names would be overkill I think.
> >
> > Everything that was already marked as deprecated in 0.20 should be
> removed
> (I think this has been done on trunk already). There are still some
> remaining references to "column" instead of "family" and also to
> family:qualifier notation. I suspect there may always be some limited
> use
> cases for that notation (like weird thing we do to pass in list of
> columns
> to MR) but we should get it out wherever we can. Now that we can pass
> Scan
> to MR maybe we can drop it there too.
> >
> > Thoughts?
> >
> > JG

Mime
View raw message