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
