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

Reply via email to