HBASE-4250 developer.xml
git-svn-id: https://svn.apache.org/repos/asf/hbase/trunk@1161277 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
Doug Meil
parent
31e9c81780
commit
b0782cbfc0
|
|
@ -83,6 +83,8 @@ Access restriction: The method getLong(Object, long) from the type Unsafe is not
|
||||||
<title>Maven Build Commands</title>
|
<title>Maven Build Commands</title>
|
||||||
<para>All commands executed from the local HBase project directory.
|
<para>All commands executed from the local HBase project directory.
|
||||||
</para>
|
</para>
|
||||||
|
<para>Note: use Maven 2, not Maven 3.
|
||||||
|
</para>
|
||||||
<section xml:id="maven.build.commands.compile">
|
<section xml:id="maven.build.commands.compile">
|
||||||
<title>Compile</title>
|
<title>Compile</title>
|
||||||
<programlisting>
|
<programlisting>
|
||||||
|
|
@ -103,29 +105,6 @@ mvn test -Dtest=TestXYZ
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
<section xml:id="unit.tests">
|
|
||||||
<title>Unit Tests</title>
|
|
||||||
<para>In HBase we use <link xlink:href="http://junit.org">JUnit</link> 4.
|
|
||||||
If you need to run miniclusters of HDFS, ZooKeeper, HBase, or MapReduce testing,
|
|
||||||
be sure to checkout the <classname>HBaseTestingUtility</classname>.
|
|
||||||
Alex Baranau of Sematext describes how it can be used in
|
|
||||||
<link xlink:href="http://blog.sematext.com/2010/08/30/hbase-case-study-using-hbasetestingutility-for-local-testing-development/">HBase Case-Study: Using HBaseTestingUtility for Local Testing and Development</link> (2010).
|
|
||||||
</para>
|
|
||||||
<section xml:id="mockito">
|
|
||||||
<title>Mockito</title>
|
|
||||||
<para>Sometimes you don't need a full running server
|
|
||||||
unit testing. For example, some methods can make do with a
|
|
||||||
a <classname>org.apache.hadoop.hbase.Server</classname> instance
|
|
||||||
or a <classname>org.apache.hadoop.hbase.master.MasterServices</classname>
|
|
||||||
Interface reference rather than a full-blown
|
|
||||||
<classname>org.apache.hadoop.hbase.master.HMaster</classname>.
|
|
||||||
In these cases, you maybe able to get away with a mocked
|
|
||||||
<classname>Server</classname> instance. For example:
|
|
||||||
<programlisting>
|
|
||||||
</programlisting>
|
|
||||||
</para>
|
|
||||||
</section>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section xml:id="getting.involved">
|
<section xml:id="getting.involved">
|
||||||
<title>Getting Involved</title>
|
<title>Getting Involved</title>
|
||||||
|
|
@ -158,10 +137,47 @@ mvn test -Dtest=TestXYZ
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
</section>
|
</section>
|
||||||
|
</section> <!-- getting involved -->
|
||||||
|
|
||||||
|
<section xml:id="developing">
|
||||||
|
<title>Developing</title>
|
||||||
<section xml:id="codelines"><title>Codelines</title>
|
<section xml:id="codelines"><title>Codelines</title>
|
||||||
<para>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).</para>
|
<para>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).</para>
|
||||||
<para>If you have any questions on this just send an email to the dev dist-list.</para>
|
<para>If you have any questions on this just send an email to the dev dist-list.</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
|
<section xml:id="unit.tests">
|
||||||
|
<title>Unit Tests</title>
|
||||||
|
<para>In HBase we use <link xlink:href="http://junit.org">JUnit</link> 4.
|
||||||
|
If you need to run miniclusters of HDFS, ZooKeeper, HBase, or MapReduce testing,
|
||||||
|
be sure to checkout the <classname>HBaseTestingUtility</classname>.
|
||||||
|
Alex Baranau of Sematext describes how it can be used in
|
||||||
|
<link xlink:href="http://blog.sematext.com/2010/08/30/hbase-case-study-using-hbasetestingutility-for-local-testing-development/">HBase Case-Study: Using HBaseTestingUtility for Local Testing and Development</link> (2010).
|
||||||
|
</para>
|
||||||
|
<section xml:id="mockito">
|
||||||
|
<title>Mockito</title>
|
||||||
|
<para>Sometimes you don't need a full running server
|
||||||
|
unit testing. For example, some methods can make do with a
|
||||||
|
a <classname>org.apache.hadoop.hbase.Server</classname> instance
|
||||||
|
or a <classname>org.apache.hadoop.hbase.master.MasterServices</classname>
|
||||||
|
Interface reference rather than a full-blown
|
||||||
|
<classname>org.apache.hadoop.hbase.master.HMaster</classname>.
|
||||||
|
In these cases, you maybe able to get away with a mocked
|
||||||
|
<classname>Server</classname> instance. For example:
|
||||||
|
<programlisting>
|
||||||
|
TODO...
|
||||||
|
</programlisting>
|
||||||
|
</para>
|
||||||
|
</section>
|
||||||
|
<section xml:id="code.standards">
|
||||||
|
<title>Code Standards</title>
|
||||||
|
<para>See <xref linkend="eclipse.code.formatting"/> and <xref linkend="common.patch.feedback"/>.
|
||||||
|
</para>
|
||||||
|
</section>
|
||||||
|
</section> <!-- unit tests -->
|
||||||
|
|
||||||
|
</section> <!-- developing -->
|
||||||
|
|
||||||
<section xml:id="submitting.patches">
|
<section xml:id="submitting.patches">
|
||||||
<title>Submitting Patches</title>
|
<title>Submitting Patches</title>
|
||||||
<section xml:id="submitting.patches.create">
|
<section xml:id="submitting.patches.create">
|
||||||
|
|
@ -194,14 +210,136 @@ mvn test -Dtest=TestXYZ
|
||||||
because the HBase community is helpful!
|
because the HBase community is helpful!
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
|
<section xml:id="common.patch.feedback">
|
||||||
|
<title>Common Patch Feedback</title>
|
||||||
|
<para>The following items are representative of common patch feedback. Your patch process will go faster if these are
|
||||||
|
taken into account <emphasis>before</emphasis> submission.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
See the <link xlink:href="http://www.oracle.com/technetwork/java/codeconv-138413.html">Java coding standards</link>
|
||||||
|
for more information on coding conventions in Java.
|
||||||
|
</para>
|
||||||
|
<section xml:id="common.patch.feedback.space.invaders">
|
||||||
|
<title>Space Invaders</title>
|
||||||
|
<para>Rather than do this...
|
||||||
|
<programlisting>
|
||||||
|
if ( foo.equals( bar ) ) { // don't do this
|
||||||
|
</programlisting>
|
||||||
|
... do this instead...
|
||||||
|
<programlisting>
|
||||||
|
if (foo.equals(bar)) {
|
||||||
|
</programlisting>
|
||||||
|
</para>
|
||||||
|
<para>Also, rather than do this...
|
||||||
|
<programlisting>
|
||||||
|
foo = barArray[ i ]; // don't do this
|
||||||
|
</programlisting>
|
||||||
|
... do this instead...
|
||||||
|
<programlisting>
|
||||||
|
foo = barArray[i];
|
||||||
|
</programlisting>
|
||||||
|
</para>
|
||||||
|
</section>
|
||||||
|
<section xml:id="common.patch.feedback.autogen">
|
||||||
|
<title>Auto Generated Code</title>
|
||||||
|
<para>Auto-generated code in Eclipse often looks like this...
|
||||||
|
<programlisting>
|
||||||
|
public void readFields(DataInput arg0) throws IOException { // don't do this
|
||||||
|
foo = arg0.readUTF(); // don't do this
|
||||||
|
</programlisting>
|
||||||
|
... do this instead ...
|
||||||
|
<programlisting>
|
||||||
|
public void readFields(DataInput di) throws IOException {
|
||||||
|
foo = di.readUTF();
|
||||||
|
</programlisting>
|
||||||
|
See the difference? 'arg0' is what Eclipse uses for arguments by default.
|
||||||
|
</para>
|
||||||
|
</section>
|
||||||
|
<section xml:id="common.patch.feedback.longlines">
|
||||||
|
<title>Long Lines</title>
|
||||||
|
<para>
|
||||||
|
Keep lines less than 80 characters.
|
||||||
|
<programlisting>
|
||||||
|
Bar bar = foo.veryLongMethodWithManyArguments(argument1, argument2, argument3, argument4, argument5); // don't do this
|
||||||
|
</programlisting>
|
||||||
|
... do this instead ...
|
||||||
|
<programlisting>
|
||||||
|
Bar bar = foo.veryLongMethodWithManyArguments(argument1,
|
||||||
|
argument2, argument3,argument4, argument5);
|
||||||
|
</programlisting>
|
||||||
|
... or this, whichever looks better ...
|
||||||
|
<programlisting>
|
||||||
|
Bar bar = foo.veryLongMethodWithManyArguments(
|
||||||
|
argument1, argument2, argument3,argument4, argument5);
|
||||||
|
</programlisting>
|
||||||
|
</para>
|
||||||
|
</section>
|
||||||
|
<section xml:id="common.patch.feedback.trailingspaces">
|
||||||
|
<title>Trailing Spaces</title>
|
||||||
|
<para>
|
||||||
|
This happens more than people would imagine.
|
||||||
|
<programlisting>
|
||||||
|
Bar bar = foo.getBar(); <--- imagine there's an extra space(s) after the semicolon instead of a line break.
|
||||||
|
</programlisting>
|
||||||
|
Make sure there's a line-break after the end of your code, and also avoid lines that have nothing
|
||||||
|
but whitespace.
|
||||||
|
</para>
|
||||||
|
</section>
|
||||||
|
<section xml:id="common.patch.feedback.writable">
|
||||||
|
<title>Implementing Writable</title>
|
||||||
|
<para>Every class returned by RegionServers must implement <code>Writable</code>. If you
|
||||||
|
are creating a new class that needs to implement this interface, don't forget the default constructor.
|
||||||
|
</para>
|
||||||
|
</section>
|
||||||
|
<section xml:id="common.patch.feedback.javadoc">
|
||||||
|
<title>Javadoc</title>
|
||||||
|
<para>This is also a very common feedback item. Don't forget Javadoc!
|
||||||
|
</para>
|
||||||
|
</section>
|
||||||
|
<section xml:id="common.patch.feedback.javadoc.defaults">
|
||||||
|
<title>Javadoc - Useless Defaults</title>
|
||||||
|
<para>Don't just leave the @param arguments the way your IDE generated them. Don't do this...
|
||||||
|
<programlisting>
|
||||||
|
/**
|
||||||
|
*
|
||||||
|
* @param bar <---- don't do this!!!!
|
||||||
|
* @return <---- or this!!!!
|
||||||
|
*/
|
||||||
|
public Foo getFoo(Bar bar);
|
||||||
|
</programlisting>
|
||||||
|
... either add something descriptive to the @param and @return lines, or just remove them.
|
||||||
|
But the preference is to add something descriptive and useful.
|
||||||
|
</para>
|
||||||
|
</section>
|
||||||
|
<section xml:id="common.patch.feedback.massreformat">
|
||||||
|
<title>Unrelated Code Formating or Auto-Reformating</title>
|
||||||
|
<para>If you submit a patch for one thing, don't do auto-reformatting or unrelated reformatting of code on a completely
|
||||||
|
different area of code.
|
||||||
|
</para>
|
||||||
|
</section>
|
||||||
|
<section xml:id="common.patch.feedback.tests">
|
||||||
|
<title>Ambigious Unit Tests</title>
|
||||||
|
<para>Make sure that you're clear about what you are testing in your unit tests and why.
|
||||||
|
</para>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
</section> <!-- patch feedback -->
|
||||||
|
|
||||||
|
<section xml:id="reviewboard">
|
||||||
|
<title>ReviewBoard</title>
|
||||||
|
<para>Larger patches should go through <link xlink:href="http://reviews.apache.org">ReviewBoard</link>.
|
||||||
|
</para>
|
||||||
</section>
|
</section>
|
||||||
<section xml:id="committing.patches">
|
<section xml:id="committing.patches">
|
||||||
<title>Committing Patches</title>
|
<title>Committing Patches</title>
|
||||||
<para>
|
<para>
|
||||||
Committers do this. See <link xlink:href="http://wiki.apache.org/hadoop/Hbase/HowToCommit">How To Commit</link> in the HBase wiki.
|
Committers do this. See <link xlink:href="http://wiki.apache.org/hadoop/Hbase/HowToCommit">How To Commit</link> in the HBase wiki.
|
||||||
</para>
|
</para>
|
||||||
|
<para>Commiters will also resolve the Jira, typically after the patch passes a build.
|
||||||
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
</section>
|
</section> <!-- submitting patches -->
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue