[DISCUSS] Change package names to org.apache.hbase

[Jonathan Gray <jg...@facebook.com>]

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

Re: [DISCUSS] Change package names to org.apache.hbase

[Stack <st...@duboce.net>]

+1

Stuff thats revealed the client like HColumnDescriptor and
HTableDescriptor would also have to stay in the o.a.h.h hierarchy.

St.Ack

On Fri, May 28, 2010 at 3:16 PM, Jonathan Gray <jg...@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
>

RE: [DISCUSS] Change package names to org.apache.hbase

[Andrew Purtell <ap...@apache.org>]

+1 given this approach

> From: Jonathan Gray 
> Subject: RE: [DISCUSS] Change package names to org.apache.hbase
> To: "dev@hbase.apache.org" <de...@hbase.apache.org>
> Date: Friday, May 28, 2010, 3:27 PM

> 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" <jg...@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
> 


      

RE: [DISCUSS] Change package names to org.apache.hbase

[Jonathan Gray <jg...@facebook.com>]

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" <jg...@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

Re: [DISCUSS] Change package names to org.apache.hbase

[Ryan Rawson <ry...@gmail.com>]

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" <jg...@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

Re: [DISCUSS] Change package names to org.apache.hbase

[Jean-Daniel Cryans <jd...@apache.org>]

+1, plus comments:

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

o.a.h.h.mapred needs to follow too, until it's removed from hadoop.

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

We already have that with mapred and mapreduce. Project still thriving :)

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

Yep that's already cleared out.

J-D