hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@apache.org>
Subject Re: [DISCUSS] Publishing hbase binaries with different hadoop release lines
Date Thu, 30 May 2019 13:06:09 GMT
What about moving back to having a per-major-version-of-hadoop
compatibility module again that builds against one needed major version all
the time? (Presumably with some shell script magic to pick the right one?)
that would be preferable imho to e.g. producing main project binary
tarballs per Hadoop version.

Or! We could move stuff that relies on brittle Hadoop internals into its
own repo (or one of our existing repos) and build _that_ with binaries for
our supported Hadoop versions. Then in the main project we can include the
appropriate artifact for the version of Hadoop we happen to build with
(essentially leaving the main repo how it is) and update our "replace the
version of Hadoop!" note to including replacing this "HBase stuff that's
closely tied to Hadoop internals" jar as well.

On Wed, May 29, 2019, 08:41 张铎(Duo Zhang) <palomino219@gmail.com> wrote:

> See the comments here
> https://issues.apache.org/jira/browse/HBASE-22394
> Although we claim that hbase 2.1.x can work together with hadoop 3.1.x,
> actually we require users to build the hbase binary with hadoop 3.1.x by
> their own if they really want to use hbase together with hadoop 3.1.x
> clients.
> The problem for HBASE-22394 is that our asyncfswal references some
> IA.Private classes and they have been changed between minor releases. It
> can be solved by using reflection. But in general, since hadoop also
> follows the semantic versioning, I do not think it is safe to do drop-in
> replacement between minor releases. So maybe a better way is to publish a
> hbase binary for each hadoop minor release line?
> Thanks.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message