hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Rawson <ryano...@gmail.com>
Subject Re: [DISCUSS] Change package names to org.apache.hbase
Date Fri, 28 May 2010 22:21:55 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message