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