Most development is done on 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).
If you have any questions on this just send an email to the dev dist-list.
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:
Also, please pay attention to the interface stability/audience classifications that you will see all over our code base. They look like this at the head of the class:
we can change the class (and we do not need to include a
If a class is marked
Public but its
Unstable, we can change it. If it's
Evolving, we're allowed to change it
but should try not to. If it's
we can't change it without a deprecation path or with a really GREAT reason.
When you add new classes, mark them with the annotations above if publically accessible. If you are not cleared on how to mark your additions, ask up on the dev list.
This convention comes from our parent project Hadoop.
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