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