我们使用 Git 进行源代码管理，并在master分支上进行最新的开发。过去的主要/次要/维护版本都有分支，重要的功能和错误修复通常会反向移植到它们。
界面按受众和稳定性级别进行分类。这些标签出现在班级的头部。 HBase 遵循的约定由其父项目 Hadoop 继承。
通常使用以下接口分类：
InterfaceAudience
@InterfaceAudience.Public
用户和 HBase 应用程序的 API。这些 API 将通过主要版本的 HBase 弃用。
@InterfaceAudience.Private
HBase 内部开发人员的 API。在将来的版本中不保证兼容性或可用性。专用接口不需要@InterfaceStability分类。
@InterfaceAudience.LimitedPrivate(HBaseInterfaceAudience.COPROC)
HBase 协处理器编写器的 API。
没有@InterfaceAudience分类
没有@InterfaceAudience标签的包被视为私有。如果可以公开访问，请标记新包。
从 API 文档中排除非公共接口
只有分类
@InterfaceAudience.Public的接口才应包含在 API 文档（Javadoc）中。对于不包含公共类的新包，提交者必须为 pom.xml 添加新包，不包括ExcludePackageNames部分。
@InterfaceStability
@InterfaceStability对标有@InterfaceAudience.Public的包很重要。
@InterfaceStability.Stable
如果没有弃用路径或非常好的理由，则无法更改标记为稳定的公共包。
@InterfaceStability.Unstable
标记为不稳定的公共包可以在没有弃用路径的情况下进行更改。
@InterfaceStability.Evolving
标记为演变的公共包可能会被更改，但不鼓励使用。
没有@InterfaceStability标签
不鼓励没有@InterfaceStability标签的公共类，并且应该将其视为隐式不稳定。
如果您不清楚如何标记包，请在开发列表中询问。
请遵循以下准则，以便更快地审核您的补丁。这些指南是基于对新贡献者的补丁的共同反馈而开发的。
有关 Java 编码约定的更多信息，请参见 Java 编程语言的代码约定。请参阅 eclipse.code.formatting 以设置 Eclipse 以自动检查其中一些指南。
不要在括号周围使用额外的空格。使用第二种风格，而不是第一种风格。
if ( foo.equals( bar ) ) { // don't do this
if (foo.equals(bar)) {
foo = barArray[ i ]; // don't do this
foo = barArray[i];
Eclipse 中自动生成的代码通常使用错误的变量名，例如arg0。使用更具信息性的变量名称。像这里的第二个例子一样使用代码。
public void readFields(DataInput arg0) throws IOException { // don't do this
foo = arg0.readUTF(); // don't do this
public void readFields(DataInput di) throws IOException {
foo = di.readUTF();
保持行少于 100 个字符。您可以将 IDE 配置为自动执行此操作。
Bar bar = foo.veryLongMethodWithManyArguments(argument1, argument2, argument3, argument4, argument5, argument6, argument7, argument8, argument9); // don't do this
Bar bar = foo.veryLongMethodWithManyArguments(
argument1, argument2, argument3,argument4, argument5, argument6, argument7, argument8, argument9);
确保在代码结束后有一个换行符，并避免只有空格的行。这使得差异更有意义。您可以配置 IDE 以帮助解决此问题。
Bar bar = foo.getBar(); <--- imagine there is an extra space(s) after the semicolon.
别忘了 Javadoc！
在预先提交期间检查 Javadoc 警告。如果预先提交工具给你一个'-1'，请修复 javadoc 问题。如果添加此类警告，则不会提交您的补丁。
此外，没有@author标签 - 这是一个规则。
Findbugs用于检测常见错误模式。在 precommit 构建期间检查它。如果发现错误，请修复它们。您可以使用mvn findbugs:findbugs在本地运行 findbugs，它将在本地生成findbugs文件。有时，您可能必须编写比findbugs更智能的代码。您可以通过使用以下注释对类进行注释来注释代码以告诉findbugs您知道自己在做什么：
@edu.umd.cs.findbugs.annotations.SuppressWarnings(
value="HE_EQUALS_USE_HASHCODE",
justification="I know what I'm doing")
使用 Apache 许可版本的注释很重要。这通常意味着在edu.umd.cs.findbugs.annotations包中使用注释，这样我们就可以依赖于洁净室重新实现而不是javax.annotations包中的注释。
不要像 IDE 生成它们那样保留 javadoc 标记，也不要在其中填充冗余信息。
/**
* @param table <---- don't leave them empty!
* @param region An HRegion object. <---- don't fill redundant information!
* @return Foo Object foo just created. <---- Not useful information
* @throws SomeException <---- Not useful. Function declarations already tell that!
* @throws BarException when something went wrong <---- really?
*/
public Foo createFoo(Bar bar);
添加描述符号的内容，或者只删除它们。首选是添加描述性和有用的东西。
如果您为一件事提交补丁，请不要在完全不同的代码区域上进行自动重新格式化或不相关的代码重新格式化。
同样，不要在 Jira 的范围之外添加不相关的清理或重构。
确保您清楚自己在单元测试中测试的内容以及原因。
适用于 0.96 之前的版本
在 0.96 中，HBase 转移到协议缓冲区（protobufs）。关于 Writables 的以下部分适用于 0.94.x 及之前，而不是 0.96 及更高版本。
RegionServers 返回的每个类都必须实现Writable接口。如果要创建需要实现此接口的新类，请不要忘记默认构造函数。
以下指南来自 http://engineering.linkedin.com/performance/linkedin-feed-faster-less-jvm-garbage 。牢记这一点，将可预防的垃圾收集工作降至最低。请查看博客文章，了解如何根据这些指南重构代码的一些很好的示例。
对迭代器要小心
初始化时估计集合的大小
推迟表达评估
提前编译正则表达式模式
如果可以，请缓存它
字符串实习生很有用但很危险
我们没有很多，但我们在下面列出了什么。当然所有都受到挑战，但在此之前，请遵守道路规则。
ZooKeeper 状态应该是瞬态的（将其视为内存）。如果删除 ZooKeeper 状态，hbase 应该能够恢复并且基本上处于相同的状态。
.Exceptions：目前我们需要解决几个例外，无论表是启用还是禁用。
复制数据当前仅存储在 ZooKeeper 中。删除与复制相关的 ZooKeeper 数据可能会导致禁用复制。不要删除复制树， / hbase / replication / 。
> 如果从 ZooKeeper 中删除复制树（ / hbase / replication / ），则可能会中断复制并导致数据丢失。在 HBASE-10295 上关注此问题的进展。
如果您正在开发 Apache HBase，那么测试您对更真实的集群的更改通常比您在单元测试中找到的更有用。在这种情况下，HBase 可以在本地模式下直接从源运行。您需要做的就是运行：
${HBASE_HOME}/bin/start-hbase.sh
这将启动一个完整的本地群集，就像您已打包 HBase 并将其安装在您的计算机上一样。
请记住，您需要将 HBase 安装到本地 maven 存储库中，以使原位群集正常工作。也就是说，您需要运行：
mvn clean install -DskipTests
确保 maven 可以找到正确的类路径和依赖项。一般来说，如果 maven 行为奇怪，上面的命令首先尝试运行是一件好事。
添加新功能后，开发人员可能希望添加指标。 HBase 使用 Hadoop Metrics 2 系统公开指标，因此添加新指标涉及将该指标公开给 hadoop 系统。不幸的是，metrics2 的 API 从 hadoop 1 变为 hadoop 2.为了解决这个问题，必须在运行时加载一组接口和实现。要深入了解这些类的推理和结构，您可以阅读这里的博客文章。要向现有 MBean 添加指标，请遵循以下简短指南：
在源接口内部，对应于生成度量的位置（例如，来自 HMaster 的事物的 MetricsMasterSource）为度量标准名称和描述创建新的静态字符串。然后添加一个将被调用以添加新读数的新方法。
在源的实现内部（例如，上例中的 MetricsMasterSourceImpl）在 init 方法中创建新的直方图，计数器，计量器或 stat。然后在添加到接口的方法中连接传入直方图的参数。
现在添加测试以确保数据正确导出到 metrics 2 系统。为此，提供了 MetricsAssertHelper。
避免 git 合并。
使用git pull --rebase或git fetch，然后按git rebase。
不要使用git push --force。
如果推送不起作用，请解决问题或寻求帮助。
如果您考虑其他 Git 最佳实践，请参与此文档。
rebase_all_git_branches.sh提供了 _dev-support / rebase_all_git branches.sh 脚本以帮助保持 Git 存储库的清洁。使用-h参数获取使用说明。该脚本会自动刷新您的跟踪分支，尝试针对其远程分支自动重新定位每个本地分支，并为您提供删除代表已关闭HBASE- JIRA 的任何分支的选项。该脚本有一个可选的配置选项，即 Git 目录的位置。您可以通过编辑脚本来设置默认值。否则，您可以使用-d参数手动传递 git 目录，然后使用绝对或相对目录名称，甚至是“。”对于当前的工作目录。在继续之前，脚本会检查目录中是否有名为 .git / 的子目录。
如果您不熟悉提交补丁到开源或新提交补丁到 Apache，请首先阅读 Apache Commons Project 中的 On Contributing Patches 页面。它提供了一个很好的概述，同样适用于 Apache HBase 项目。
请务必查看 common.patch.feedback 的代码样式。如果您的补丁生成不正确或您的代码不符合代码格式指南，则可能会要求您重做某些工作。
使用 submit-patch.py（推荐）
$ dev-support/submit-patch.py -jid HBASE-xxxxx
使用此脚本创建修补程序，上传到 jira 并可选择在 Review Board 上创建/更新评论。补丁名称自动格式化为 _（JIRA）。（分支名称）。（补丁号）。补丁 _ 遵循 Yetus 的命名规则。使用-h标志了解详细的使用信息。最有用的选项是：
-b BRANCH, --branch BRANCH：指定用于生成 diff 的基本分支。如果未指定，则使用跟踪分支。如果没有跟踪分支，则会抛出错误。
-jid JIRA_ID, --jira-id JIRA_ID：如果使用，则从 jira 中的附件推断下一个补丁版本并上传新补丁。脚本将要求 jira 用户名/密码进行身份验证。如果未设置，则将补丁命名为 <branch>.patch。</branch>
默认情况下，它还会创建/更新审核委员会。要跳过该操作，请使用-srb选项。它使用 jira 中的“问题链接”来确定审核请求是否已存在。如果没有审核请求，则创建一个新请求并使用 jira 摘要，补丁说明等填充所有必填字段。此外，还将此评论的链接添加到 jira。
保存身份验证凭据（可选）
由于在 JIRA 上附加补丁并在 ReviewBoard 上创建/更改审阅请求需要有效的用户身份验证，因此脚本将提示您输入用户名和密码。为了避免每次麻烦，请使用登录详细信息设置~/.apache-creds并按照脚本帮助消息页脚中的步骤对其进行加密。
Python 依赖项
要安装所需的 python 依赖项，请从 master 分支执行pip install -r dev-support/python-requirements.txt。
手动
首先使用git rebase -i，将较小的提交组合（压缩）到一个较大的提交中。
使用 IDE 或 Git 命令创建补丁。 git format-patch是首选，因为它保留了补丁作者的姓名和提交消息。此外，它默认处理二进制文件，而git diff忽略它们，除非您使用--binary选项。
补丁名称应如下符合 Yetus 的命名约定：(JIRA).(branch name).(patch number).patch例如。 HBASE-11625.master.001.patch，HBASE-XXXXX.branch-1.2.0005.patch 等
使用More→Attach Files将补丁附加到 JIRA，然后单击 Submit Patch 按钮，这将触发 Hudson 作业以检查补丁的有效性。
如果您的补丁长于单个屏幕，还可以在 Review Board 上创建评论并添加指向 JIRA 的链接。参见评论板。
一般指导原则很少
即使您要在另一个分支中进行修补，也要始终首先修补主分支。 HBase 提交程序始终首先将修补程序应用于主分支，并在必要时应用反向端口。
提交一个修补程序的单个修补程序。如有必要，首先将本地提交压缩为单个提交。有关压缩提交的更多信息，请参阅此堆栈溢出问题。
请理解并非每个补丁都可能会被提交，并且可能会在补丁上提供反馈。
如果您需要修改补丁，请将之前的补丁文件保留在 JIRA 上，然后上传一个补丁编号增加的补丁文件。单击取消补丁，然后单击提交补丁以触发预提交运行。
在进行更改时始终添加和/或更新相关的单元测试。在提交补丁之前确保新的/更改的单元测试在本地通过，因为它比等待运行完整测试套件的预提交结果更快。这将节省您自己的时间和精力。使用 mockito 制作模拟，这些模拟对于通过注入适当的故障来测试故障情况非常有用。
如果要创建新的单元测试类，请注意其他单元测试类在类名称之前是否具有分类/大小调整注释以及用于设置/拆除测试环境的静态方法。请务必在任何新的单元测试文件中包含注释。有关测试的更多信息，请参见 hbase.tests 。
除了单元测试之外，重要的新功能还应提供集成测试，适用于在其配置空间的不同点执行新功能。
大于一个屏幕的补丁或者难以查看的补丁应该通过 ReviewBoard 。
过程：使用 ReviewBoard
如果您还没有帐户，请注册一个帐户。它不使用 issues.apache.org 的凭据。登录。
单击“新建审阅请求”
选择hbase-git存储库。单击“选择文件”以选择差异和可选的父差异。单击创建审核请求。
根据需要填写字段。至少，填写摘要并选择hbase作为审核组。如果您填写 Bugs 字段，审核委员会会链接回相关的 JIRA。您填写的字段越多越好。点击发布即可公开您的评论请求。将向hbase组中的每个人发送一封电子邮件，以查看该补丁。
返回 JIRA，单击并粘贴 ReviewBoard 请求的 URL。这将 ReviewBoard 附加到 JIRA，以便于访问。
要取消请求，请单击。
有关如何使用 ReviewBoard 的更多信息，请参阅 ReviewBoard 文档。
提交者负责审查和整合代码更改，测试和投票候选版本，权衡设计讨论以及其他类型的项目贡献。 PMC 根据对项目贡献的评估，投票决定让贡献者成为提交者。预计提交者将展示对项目和社区参与的高质量贡献的持续历史。
贡献可以通过多种方式进行。成为提交者没有单一的途径，也没有任何预期的时间表。提交功能，改进和错误修复是最常见的途径，但其他方法都得到了认可和鼓励（对于 HBase 作为项目和社区的健康状况可能更为重要）。潜在贡献的非详尽清单（无特定顺序）：
更新文档以了解新的更改，最佳做法，配方和其他改进。
使网站保持最新。
执行测试并报告结果。例如，总是赞赏尺度测试和测试非标准配置。
维护共享的 Jenkins 测试环境和其他测试基础架构。
在执行验证后投票发布候选，即使不具有约束力。非约束性投票是非提交者的投票。
为邮件列表（通常在主题行中有[DISCUSS]）的讨论主题提供输入。
回答用户或开发人员邮件列表和 Slack 上的问题。
确保 HBase 社区是一个热情的社区，并且我们遵守我们的行为准则。如果您有疑虑，请提醒 PMC。
查看其他人的工作（代码和非代码）并提供公众反馈。
报告找到的错误或提交新功能请求。
分类问题并保持 JIRA 的组织。这包括根据需要关闭陈旧问题，标记新问题，更新元数据和其他任务。
各种导师的新贡献者。
谈谈和写关于 HBase 的博客。将这些添加到网站的新闻部分。
提供有关 HBase，Web UI，CLI，API 和网站的 UX 反馈。
编写演示应用程序和脚本。
帮助吸引和留住多元化的社区。
以有利于 HBase 和其他项目的方式与其他项目互动。
并非每个人都能够完成此列表中的所有（甚至任何）项目。如果您想到其他贡献方式，请选择它（并将它们添加到列表中）。为了对 HBase 项目产生积极影响，您需要一个愉快的风度和贡献的意愿。邀请成为提交者是长期与社区稳定互动的结果，这建立了信任和认可。
鼓励新的提交者首先阅读 Apache 的通用提交者文档：
HBase 提交者应尽可能多地尝试审查其他人提交的补丁。理想情况下，每个提交的补丁都会在几天内由提交者 _ 审核 _。如果提交者审查他们没有创作的补丁，并认为它具有足够的质量，那么他们可以提交补丁。否则，应该取消补丁，并清楚解释它被拒绝的原因。
提交的补丁列表位于 HBase Review Queue 中，该队列按上次修改时间排序。提交者应该从上到下扫描列表，寻找他们认为有资格审查并可能提交的补丁。如果您看到一个补丁，您认为其他人更有资格审核，您可以在 JIRA 中通过用户名提及它们。
对于非平凡的更改，需要另一个提交者在提交之前检查您的修补程序。 不允许自行提交非平凡补丁。 使用 JIRA 中的 Submit Patch 按钮，就像其他贡献者一样，然后在提交之前等待来自另一个提交者的+1响应。
应拒绝不符合 HowToContribute 和代码审查清单中的指南的补丁。提交者应始终对贡献者保持礼貌，并尝试指导并鼓励他们提供更好的补丁。如果提交者希望改进不可接受的补丁，那么首先应该拒绝补丁，并且应该由提交者附加新的补丁以供进一步审查。
提交者向 Apache HBase GIT 存储库提交补丁。
在你提交之前！
确保您的本地配置正确，尤其是您的身份和电子邮件。检查$ git config --list 命令的输出并确保它是正确的。如果需要指针，请参阅设置 Git 。
提交补丁时：
在提交消息中包含 Jira 问题 ID 以及更改的简短描述。尝试添加不仅仅是 Jira 标题的东西，以便有人看git log输出不必去 Jira 来辨别变化是什么。确保问题 ID 正确，因为这会导致 Jira 链接到 Git 中的更改（使用问题的“所有”选项卡查看这些自动链接）。
将补丁提交到基于master或其他预期分支的新分支。在这个分支的名称中包含 JIRA ID 是个好主意。查看要提交的相关目标分支，并通过执行 git pull --rebase 或其他类似命令确保本地分支具有所有远程更改。接下来，樱桃选择每个相关分支（例如 master）的更改，并使用 git push <remote-server><remote-branch>等命令将更改推送到远程分支。</remote-branch></remote-server>
> 如果您没有进行所有远程更改，则推送将失败。如果推送因任何原因失败，请解决问题或寻求帮助。不要做 git push --force。
在提交补丁之前，您需要确定补丁的创建方式。围绕创建补丁的方式的说明和偏好已经改变，并且将存在过渡期。
确定修补程序的创建方式
如果补丁的前几行看起来像电子邮件的标题，带有 From，Date 和 Subject，则使用 git format-patch 创建。这是首选方法，因为您可以重用提交者的提交消息。如果提交消息不合适，您仍然可以使用提交，然后根据需要运行git commit --amend和 reword。
如果补丁的第一行看起来类似于以下内容，则使用 git diff 创建而不使用--no-prefix。这也是可以接受的。注意文件名前面的a和b。这表明补丁不是用--no-prefix创建的。
diff --git a/src/main/asciidoc/_chapters/developer.adoc b/src/main/asciidoc/_chapters/developer.adoc
如果补丁的第一行看起来类似于以下（没有a和b），则补丁是使用 git diff --no-prefix 创建的，您需要将-p0添加到下面的 git apply 命令中。
diff --git src/main/asciidoc/_chapters/developer.adoc src/main/asciidoc/_chapters/developer.adoc
示例 43.提交补丁的示例
你会注意到这些例子的一件事是有很多 git pull 命令。实际将任何东西写入远程存储库的唯一命令是 git push，你需要确保你拥有正确的所有版本，并且在推送之前没有任何冲突。额外的 git pull 命令通常是多余的，但比抱歉更安全。
第一个示例显示如何应用使用 git format-patch 生成的补丁并将其应用于master和branch-1分支。
使用 git format-patch 而不是 git diff 而不使用--no-prefix的指令是一个新指令。请参阅第二个示例，了解如何应用使用 git diff 创建的补丁，并教育创建补丁的人员。
$ git checkout -b HBASE-XXXX
$ git am ~/Downloads/HBASE-XXXX-v2.patch --signoff # If you are committing someone else's patch.
$ git checkout master
$ git pull --rebase
$ git cherry-pick <sha-from-commit>
# Resolve conflicts if necessary or ask the submitter to do it
$ git pull --rebase # Better safe than sorry
$ git push origin master
# Backport to branch-1
$ git checkout branch-1
$ git pull --rebase
$ git cherry-pick <sha-from-commit>
# Resolve conflicts if necessary
$ git pull --rebase # Better safe than sorry
$ git push origin branch-1
$ git branch -D HBASE-XXXX
此示例显示如何提交使用 git diff 而不使用--no-prefix创建的修补程序。如果使用--no-prefix创建补丁，请将-p0添加到 git apply 命令。
$ git apply ~/Downloads/HBASE-XXXX-v2.patch
$ git commit -m "HBASE-XXXX Really Good Code Fix (Joe Schmo)" --author=<contributor> -a # This and next command is needed for patches created with 'git diff'
$ git commit --amend --signoff
$ git checkout master
$ git pull --rebase
$ git cherry-pick <sha-from-commit>
# Resolve conflicts if necessary or ask the submitter to do it
$ git pull --rebase # Better safe than sorry
$ git push origin master
# Backport to branch-1
$ git checkout branch-1
$ git pull --rebase
$ git cherry-pick <sha-from-commit>
# Resolve conflicts if necessary or ask the submitter to do it
$ git pull --rebase # Better safe than sorry
$ git push origin branch-1
$ git branch -D HBASE-XXXX
将问题解决为固定的，感谢贡献者。此时始终设置“修复版本”，但仅为已提交更改的每个分支设置单个修订版本，即将在其中显示更改的分支中的最早版本。
提交消息应包含 JIRA ID 以及修补程序的功能描述。首选的提交消息格式为：
<jira-id> <jira-title> (<contributor-name-if-not-commit-author>)
HBASE-12345 Fix All The Things (jane@example.com)
如果贡献者使用 git format-patch 生成补丁，则他们的提交消息在他们的补丁中，您可以使用它，但请确保 JIRA ID 位于提交消息的前面，即使贡献者将其遗漏。
我们已经建立了承诺掌握的做法，然后尽可能地回到分支机构，除非
它正在打破 compat：在这种情况下，如果它可以进入次要版本，则向后移植到 branch-1 和 branch-2。
这是一个新功能：对于维护版本不适用，对于次要版本，讨论并达成共识。
当存在轻微冲突时，我们可以修复它并继续提交。生成的提交保留原始作者。当修改作者与原始提交者不同时，在提交消息的末尾添加以下内容：Amending-Author: Author <committer&apache>参见[HBase，mail＃dev - 讨论的讨论修改提交时的最佳实践从主人到分店挑选]。
作为一个项目，我们努力确保每个变更都有一个 JIRA，但我们并未要求任何特定工具用于评审。由于 ASF 在托管的 git 存储库和 GitHub 之间的集成的实现细节，PMC 无法直接关闭我们的 GitHub 存储库上的 PR。如果贡献者在 GitHub 上发出了拉取请求，或者因为贡献者发现比将补丁附加到 JIRA 更容易，或者因为审阅者更喜欢用于检查更改的 UI，那么在提交中记下 PR 是很重要的。到主分支，以便 PR 保持最新。
要阅读有关 GitHub“close via keyword in commit”机制的提示消息的详细信息，请参阅 GitHub 文档“使用关键字关闭问题”。总之，您应该包含一个包含短语“closing #XXX”的行，其中 XXX 是拉取请求 ID。拉取请求 ID 通常在主题标题末尾的灰色 GitHub UI 中给出。
如果提交者提交补丁，他们有责任确保它通过测试套件。如果贡献者注意他们的补丁不会破坏 hbase 构建和/或测试，那么这是有帮助的，但最终，不能指望贡献者知道像 HBase 这样的项目中发生的所有特定变幻莫测和互连。提交者应该。
在线程 HBase，邮件#dev - 通知：Git Migration In Progress（WAS⇒Re：Git Migration）中，对以下补丁流程达成了一致意见
首先开发并提交针对 master 的补丁。
如果可能的话，尝试在向后移动时挑选补丁。
如果这不起作用，请手动将修补程序提交到分支。
避免合并提交，因为它们会在 git 历史记录中产生问题。
参见文献的附录。
提交者应该在 irc.freenode.net 的#hbase 会议室中进行实时讨论。但是，任何实质性讨论（与任何列表项目相关的讨论一样）都应该在 Jira 或开发人员列表中重新进行。
拼写错误和/或错误的语法比 JIRA 评论编辑导致的中断更可取：参见上的讨论 Re：（HBASE-451）从 HRegionInfo 中删除 HTableDescriptor
为 hbase-2.0.0 的发布创建了一个新项目。它被称为hbase-thirdparty。该项目仅用于为主 hbase 项目提供流行的第三方库（如番石榴，netty 和 protobuf）的重定位或阴影版本。主线 HBase 项目依赖于从 hbase-thirdparty 获取的这些库的重定位版本，而不是在通常位置查找这些类。我们这样做，所以我们可以指定我们希望的任何版本。如果我们不重新定位，我们必须协调我们的版本以匹配 hadoop，spark 和其他项目使用的版本。
对于开发人员来说，这意味着你需要小心引用 netty，guava，protobuf，gson 等类。（参见 hbase-thirdparty pom.xml 提供的内容）。开发人员必须参考 hbase-thirdparty 提供的类。在实践中，这通常不是问题（虽然它可能有点痛苦）。您将不得不寻找特定类的重定位版本。您可以通过添加org.apache.hbase.thirdparty.的常规重定位前缀来找到它。例如，如果您正在寻找com.google.protobuf.Message，HBase 内部使用的重新定位版本可以在org.apache.hbase.thirdparty.com.google.protobuf.Message中找到。
对于一些第三方库，比如 protobuf（参见本书中的 protobuf 章节了解原因），你的 IDE 可能会给你两个选项 - com.google.protobuf. 和org.apache.hbase.thirdparty.com.google.protobuf. - 因为这两个类都在你的 CLASSPATH。除非您正在进行协处理器端点开发所需的特定杂耍（再次参见上面引用的 protobuf 章节），否则您将始终使用着色版本。
hbase-thirdparty项目的 groupid 为org.apache.hbase.thirdparty。在撰写本文时，它提供了三个罐子;一个用于hbase-thirdparty-netty的人工制造，一个用于hbase-thirdparty-protobuf的 protobuf，然后是一个罐子用于其他所有 - gson，番石榴 - 在hbase-thirdpaty-miscellaneous。
hbase-thirdparty 工件是由 HBase 项目管理委员会支持下的 Apache HBase 项目生成的产品。发布是通过 hbase dev 邮件列表上的常规投票项目完成的。如果在 hbase-thirdparty 中出现问题，请使用 hbase JIRA 和邮件列表发布通知。
HBase 相关 Maven 原型的开发始于 HBASE-14876 。有关 hbase-archetypes 基础结构的概述以及开发新的 HBase 相关 Maven 原型的说明，请参阅hbase/hbase-archetypes/README.md。