+1 given this approach > From: Jonathan Gray > Subject: RE: [DISCUSS] Change package names to org.apache.hbase > To: "dev@hbase.apache.org" <dev@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:ryano...@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 >
