I have received a ton of invaluable feedback from Josh, and some good questions from Guanghao Zhang.
I am at the point where I am polishing the whitespaces and preparing to update the documentation. It would be great to hear some reviews from the SFDC side as well. (even/especially if it is "this is great, carry on!", or a +1 :) ) It is likely that the very same approach could be used for unifying the 4.x branches, so that we'd end up with two development branches, instead of the current four, which would be a huge win for maintainability. On Thu, Jan 23, 2020 at 4:14 PM Istvan Toth <st...@apache.org> wrote: > 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/> >> ------------------------------ >> >
