I have updated https://github.com/apache/phoenix/pull/687
I consider this version mostly finished. (Still only for HBase 2.x) I have abandoned the idea of a runtime compatibility solution, as the all-important shaded thick client would become unmanageable with two different HBase client runtimes. Please review and comment! On Wed, Jan 22, 2020 at 12:41 PM István Tóth <st...@cloudera.com> wrote: > Hi! > > In case not everyone on thread watches the ticket, I have put up a POC PR > for the build-time compatibility module solution. > > It is for master/HBase 2.x. I did not investigate how well this approach > would fit incorporating HBase 1.x compatibility. > > I also plan to investigate how easily this can be converted to selecting > the compatibility layer implementation at runtime, and have a single > artifact. > > On Wed, Jan 15, 2020 at 6:22 PM Andrew Purtell <andrew.purt...@gmail.com> > wrote: > >> I suppose so, but release building is scripted. The build script can >> iterate over a set of desired HBase version targets and drive the build by >> setting parameters on the maven command line. >> >> >> > On Jan 15, 2020, at 2:01 AM, Guanghao Zhang <zghao...@gmail.com> wrote: >> > >> > >> >> >> >> >> >> Anyway let’s assume for now you want to unify all the branches for >> HBase >> >> 1.x. Start with the lowest HBase version you want to support. Then >> iterate >> >> up to the highest HBase version you want to support. Whenever you run >> into >> >> compile problems, make a new version specific maven module, add logic >> to >> >> the parent POM that chooses the right one. Then for each implicated >> file, >> >> move it into the version specific maven modules, duplicating as >> needed, and >> >> finally fixing up where needed. >> >> >> > +1. So we want to use one branch to handle all hbase branches? But we >> still >> > need to release multi src/bin tar for multi hbase versions? >> > >> > Andrew Purtell <andrew.purt...@gmail.com> 于2020年1月15日周三 上午10:55写道： >> > >> >> Take PhoenixAccessController as an example. Over time the HBase >> interfaces >> >> change in minor ways. You’ll need different compilation units for this >> >> class to be able to compile it across a wide range of 1.x. However the >> >> essential Phoenix functionality does not change. The logic that makes >> up >> >> the method bodies can be factored into a class that groups together >> static >> >> helper methods which come to contain this common logic. The common >> class >> >> can remain in the core module. Then all you have in the version >> specific >> >> modules is scaffolding. In that scaffolding, calls to the static >> methods in >> >> core. It’s not a clever refactor but is DRY. Over time this can be made >> >> cleaner case by case where the naive transformation has a distasteful >> >> result. >> >> >> >> >> >>> On Jan 14, 2020, at 6:40 PM, Andrew Purtell <andrew.purt...@gmail.com >> > >> >> wrote: >> >>> >> >> >> > > > -- > *István Tóth* | Sr. Software Engineer > t. (36) 70 283-1788 > st...@cloudera.com <https://www.cloudera.com> > [image: Cloudera] <https://www.cloudera.com/> > [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: > Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: > Cloudera on LinkedIn] <https://www.linkedin.com/company/cloudera> > <https://www.cloudera.com/> > ------------------------------ >
