Most development is done on the master branch (TRUNK). However, there are branches for minor releases (e.g., 0.90.1, 0.90.2, and 0.90.3 are on the 0.90 branch).
In HBase we use JUnit 4.
If you need to run miniclusters of HDFS, ZooKeeper, HBase, or MapReduce testing,
be sure to checkout the
Alex Baranau of Sematext describes how it can be used in
HBase Case-Study: Using HBaseTestingUtility for Local Testing and Development (2010).
Sometimes you don't need a full running server
unit testing. For example, some methods can make do with a
Interface reference rather than a full-blown
In these cases, you maybe able to get away with a mocked
Server instance. For example:
Interfaces are classified both by audience and by stability level. These labels appear at the head of a class. The conventions followed by HBase are inherited by its parent project, Hadoop.
The following interface classifications are commonly used:
APIs for users and HBase applications. These APIs will be deprecated through major versions of HBase.
APIs for HBase internals developers. No guarantees on
compatibility or availability in future versions. Private interfaces
do not need an
APIs for HBase coprocessor writers. As of HBase 0.92/0.94/0.96/0.98 this api is still unstable. No guarantees on compatibility with future versions.
Packages without an
@InterfaceAudience label are
considered private. Mark your new packages if publicly
Only interfaces classified
be included in API documentation (Javadoc). Committers must add new package
ExcludePackageNames section of the
pom.xml for new packages which do not contain
@InterfaceStability is important for packages marked
Public packages marked as stable cannot be changed without a deprecation path or a very good reason.
Public packages marked as unstable can be changed without a deprecation path.
Public packages marked as evolving may be changed, but it is discouraged.
Public classes with no
@InterfaceStability label are
discouraged, and should be considered implicitly unstable.
If you are unclear about how to mark packages, ask on the development list.
We don't have many but what we have we list below. All are subject to challenge of course but until then, please hold to the rules of the road.
ZooKeeper state should transient (treat it like memory). If deleted, hbase should be able to recover and essentially be in the same state.
If you are developing Apache HBase, frequently it is useful to test your changes against a more-real cluster than what you find in unit tests. In this case, HBase can be run directly from the source in local-mode. All you need to do is run:
This will spin up a full local-cluster, just as if you had packaged up HBase and installed it on your machine.
Keep in mind that you will need to have installed HBase into your local maven repository for the in-situ cluster to work properly. That is, you will need to run:
mvn clean install -DskipTests
to ensure that maven can find the correct classpath and dependencies. Generally, the above command is just a good thing to try running first, if maven is acting oddly.
After adding a new feature a developer might want to add metrics. HBase exposes metrics using the Hadoop Metrics 2 system, so adding a new metric involves exposing that metric to the hadoop system. Unfortunately the API of metrics2 changed from hadoop 1 to hadoop 2. In order to get around this a set of interfaces and implementations have to be loaded at runtime. To get an in-depth look at the reasoning and structure of these classes you can read the blog post located here. To add a metric to an existing MBean follow the short guide below:
Inside of the source interface the corresponds to where the metrics are generated (eg MetricsMasterSource for things coming from HMaster) create new static strings for metric name and description. Then add a new method that will be called to add new reading.
Inside of the implementation of the source (eg. MetricsMasterSourceImpl in the above example) create a new histogram, counter, gauge, or stat in the init method. Then in the method that was added to the interface wire up the parameter passed in to the histogram.
Now add tests that make sure the data is correctly exported to the metrics 2 system. For this the MetricsAssertHelper is provided.
 There are currently a few exceptions that we need to fix around whether a table is enabled or disabled