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 HBaseTestingUtility
.
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
a org.apache.hadoop.hbase.Server
instance
or a org.apache.hadoop.hbase.master.MasterServices
Interface reference rather than a full-blown
org.apache.hadoop.hbase.master.HMaster
.
In these cases, you maybe able to get away with a mocked
Server
instance. For example:
TODO...
See Section 15.2.1.1, “Code Formatting” and Section 15.11.5, “Common Patch Feedback”.
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:
@InterfaceAudience.Public @InterfaceStability.Stable
If the InterfaceAudience
is Private
,
we can change the class (and we do not need to include a InterfaceStability
mark).
If a class is marked Public
but its InterfaceStability
is marked Unstable
, we can change it. If it's
marked Public
/Evolving
, we're allowed to change it
but should try not to. If it's Public
and Stable
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[29].
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:
${HBASE_HOME}/bin/start-hbase.sh
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.
[29] There are currently a few exceptions that we need to fix around whether a table is enabled or disabled