Mirror of Apache HBase Third Party Libs

Clone this repo:
  1. 902982b Preparing development version 4.1.8-SNAPSHOT by Duo Zhang · 7 weeks ago master
  2. 15182c1 Preparing hbase-thirdparty release 4.1.7RC0; tagging and updates to CHANGES.md and RELEASENOTES.md by Duo Zhang · 7 weeks ago 4.1.7RC0 rel/4.1.7
  3. d7883b5 HBASE-28493 [hbase-thirdparty] Bump protobuf version (#117) by Duo Zhang · 7 weeks ago
  4. 83ac4a7 HBASE-28492 [hbase-thirdparty] Bump dependency versions before releasing (#115) by Duo Zhang · 7 weeks ago
  5. 59dd9e3 HBASE-28491 Bump netty to 4.1.108.Final for addressing CVE-2024-29025 (#114) by Nikita Pande · 7 weeks ago

HBase Thirdparty

This project packages relocated third-party libraries used by Apache HBase.

DISCLAIMER: This project is for Apache HBase internal use. Included libs and/or their versions are subject to change at the dictate of hbase without regard to the concern of others!

We have a number of submodules, one per ornery lib -- protobuf, netty, &c. -- where we need special-handling and then a bucket for all the rest, hbase-shaded-miscellaneous. This latter includes protobuf-util, gson, and guava.

General philosophy is many modules rather than a few fat ones so we can keep dependency narrow; a fat jar would put a load of unnecessaries on the CLASSPATH. The hbase-shaded-miscellaneous is a sort of all-the-rest but it is also libs that depend on each other and are awkward to disentangle.

All shading is done using the same relocation offset of org.apache.hbase.thirdparty. We add this prefix to the relocated thirdparty library class names.

See the pom.xml for the explicit version of each third-party lib included.

Note that in hbase-shaded-protobuf, we unzip the protobuf jar to src/main/java rather than to a dir under target because the jar plugin wants src here (its hard to convince it otherwise). We also apply some patches. Current set are:


Ideally we would be pushing this set up into protobuf project.

Note that this project requires JDK8. This is because a bunch of the code we have in hbase-unsafe is using old APIs that have been removed from more modern JDKs. Due to a bug in JDK, we cannot generate this code using a more modern version of the JDK. See HBASE-26773 for details.


To build, make sure that your environment uses JDK8, then just run:

mvn clean package


To cut a release candidate, update JIRA. The hbase-thirdparty currently uses hbase JIRA but with versions specified with a ‘thirdparty-x.y.z’.

Use the dev-support/create-release scripts found in hbase.git:master. This requires having the gpg-agent running and configured correctly. Specify the project name and git repo path. See do-release-docker.sh -h for details. For example:

% mkdir ~/tmp/hbase-thirdparty-4.1.6RC0/
% ~/src/hbase/dev-support/create-release/do-release-docker.sh \
    -d ~/tmp/hbase-thirdparty-4.1.6RC0 \
    -p hbase-thirdparty

Try the new artifact by having hbase use the staged jar. Do this in your hbase pom:

diff --git a/pom.xml b/pom.xml
index 112f95a892..dab9e7a6bd 100755
--- a/pom.xml
+++ b/pom.xml
@@ -1451,7 +1451,7 @@
-    <hbase-thirdparty.version>2.1.0</hbase-thirdparty.version>
+    <hbase-thirdparty.version>2.2.0</hbase-thirdparty.version>
     <!-- Intraproject jar naming properties -->
     <!-- TODO this is pretty ugly, but works for the moment.
       Modules are pretty heavy-weight things, so doing this work isn't too bad. -->
@@ -3774,4 +3774,11 @@
+  <repositories>
+    <repository>
+      <id>staging</id>
+      <name>staging</name>
+      <url>https://repository.apache.org/content/repositories/orgapachehbase-1296</url>
+    </repository>
+  </repositories>

Send out an email with details on staging repo and pointers to the uploaded artifacts.