Page History

...

This page describes the mechanics of how to contribute software to Apache Hive. For ideas about what you might contribute, please see open tickets in Jira.

Getting the Source Code

First of all, you need the Hive source code.  As of April 2015 Hive has moved to git for its repository.

Get the source code on your local drive using SVNgit. Most development is done on the "trunkmaster":

svngit checkoutclone httphttps://svngit-wip-us.apache.org/repos/asf/hive/trunk hive-trunk

You also have the option of using one of the Git mirrors of the SVN repository:

git clone git://git.apache.org/hive.git

or

git clone http://github.com/apache/hive.git

Setting Up Eclipse Development Environment (Optional)

This is an optional step. Eclipse has a lot of advanced features for Java development, and it makes the life much easier for Hive developers as well.

How do I import into eclipse?

Becoming a Contributor

This checklist tells you how to create accounts and obtain permissions needed by Hive contributors.  See the Hive website for additional information.

.git

Setting Up Eclipse Development Environment (Optional)

This is an optional step. Eclipse has a lot of advanced features for Java development, and it makes the life much easier for Hive developers as well.

How do I import into eclipse?

Becoming a Contributor

This checklist tells you how to create accounts and obtain permissions needed by Hive contributors.  See the Hive website for additional information.

•  Create an Apache Software Foundation JIRA account if you do not already have one:  Sign Up for JIRA.
  • The ASF JIRA system dashboard is here.
  • The Hive JIRA is here. 
•  To review patches for JIRA tickets, use the Review Board.  If you need an account, register here.  See Review Process below for more information.
  • All Hive patches posted for review are listed here.
  • Individual JIRA tickets provide a link to the issue on the review
•  Create an Apache Software Foundation JIRA account if you do not already have one:  Sign Up for JIRA.
  • The ASF JIRA system dashboard is here.
  • The Hive JIRA is here. 
•  To review patches for JIRA tickets, use the Review Board.  If you need an account, register here.  See Review Process below for more information.
  • All Hive patches posted for review are listed here.
  • Individual JIRA tickets provide a link to the issue on the review board when a review request has been made.
  • For simple reviews, you can just read the patch attached to the JIRA ticket and post a comment.
•  To contribute to the Hive wiki, follow the instructions in About This Wiki.
•  To edit the Hive website, follow the instructions in How to edit the website.
•  Join the Hive mailing lists to receive email about issues and discussions.

...

• Normal unit test: These are used by testing a particular component of Hive.
  • We just need to add a new class (name must start with "Test") in */src/test directory.
  • We can run "mvn test -Dtest=TestAbc -Phadoop-1" where TestAbc is the name of the new class. This will test only the new testcase, which will be faster than "mvn test -Phadoop-1" which tests all testcases.
• A new query: If the new feature can be tested using Hive command line, we just need to add a new *.q file and a new *.q.out file:
  • If the feature is added in ql
    • Add a new XXXXXX.q file in ql/src/test/queries/clientpositive.
    • Run "mvn test -Phadoop-1 -Dtest=TestCliDriver -Dqfile=XXXXXX.q -Dtest.output.overwrite=true". This will generate a new XXXXXX.q.out file in ql/src/test/results/clientpositive.
      • If you want to run multiple .q files in the test run, you can specify comma separated .q files, for example -Dqfile="X1.q,X2.q". You can also specify a Java regex, for example -Dqfile_regex='join.*'. (Note that it takes Java regex, i.e., 'join.*' and not 'join*'). The regex match first removes the .q from the file name before matching regex, so specifying "join*.q" will not work.
    • If you are using hive-0.11.0 or later, you can specify "-Dmodule=ql".
  • If the feature is added in contrib
    • Do the steps above, replacing "ql" with "contrib", and "TestCliDriver" with "TestContribCliDriver".
    • If you are using hive-0.11.0 or later, you can specify "-Dmodule=contrib".

Debugging

Please see Debugging Hive code in Development Guide.

Creating a Patch

Check to see what files you have modified with:

svn stat

Add any new files with:

svn add .../MyNewClass.java
svn add .../TestMyNewClass.java
svn add .../XXXXXX.q
svn add .../XXXXXX.q.out

In order to create a patch, type (from the base directory of Hive):

svn diff > HIVE-1234.1.patch

This will report all modifications done on Hive sources on your local disk and save them into the HIVE-1234.1.patch file. Read the patch file. Make sure it includes ONLY the modifications required to fix a single issue.

• • • • regex, i.e., 'join.*' and not 'join*'). The regex match first removes the .q from the file name before matching regex, so specifying "join*.q" will not work.
    • If you are using hive-0.11.0 or later, you can specify "-Dmodule=ql".
  • If the feature is added in contrib
    • Do the steps above, replacing "ql" with "contrib", and "TestCliDriver" with "TestContribCliDriver".
    • If you are using hive-0.11.0 or later, you can specify "-Dmodule=contrib".

Debugging

Please see Debugging Hive code in Development Guide.

Creating a Patch

After you have committed a change or set of changes to your local repository, you need to create a patch to post on the JIRA.  The naming convention for patches is:

HIVE-<JIRA-NUMBER>[.<patch-num>][-<branch-name>].patch

<patch-num> is only required if it is not the first patch

<branch-name> is only required if it is not master

So the first patch for JIRA HIVE-9999 intended to be applied to master would be named HIVE-9999.patch

The second patch for the same JIRA would be named HIVE-9999.2.patch

A patch for the same JIRA intended to be applied to the llap branch would be named HIVE-9999-llap.patchIf you are using Git instead of Subversion, it's important that you generate your patch using the following command:

git diff --no-prefix <commit> > HIVE-1234.1.patch

Please do not:

• reformat code unrelated to the bug being fixed: formatting changes should be separate patches/commits.
• comment out code that is now obsolete: just remove it.
• insert comments around each change, marking the change: folks can use subversion to figure out what's changed and by whom.
• make things public which are not required by end users.

Please do:

• try to adhere to the coding style of files you edit;
• comment code whose function or rationale is not obvious;
• update documentation (e.g., package.html files, hive-default.xml.template, this wiki, etc.)

If you need to rename files in your patch:

1. Write a shell script that uses 'svn mv' to rename the original files.
2. Edit files as needed (e.g., to change package names).
3. Create a patch file with 'svn diff --no-diff-deleted --notice-ancestry'.
4. Submit both the shell script and the patch file.

...

<commit> is the last commit from Hive (not you) before your commits.  Note that if it has been a while since you fetched or pulled from the Hive repository you may need to do a rebase to get you commit(s) on top in order to create a patch that will cleanly apply.

Please do not:

• reformat code unrelated to the bug being fixed: formatting changes should be separate patches/commits.
• comment out code that is now obsolete: just remove it.
• insert comments around each change, marking the change: folks can use subversion to figure out what's changed and by whom.
• make things public which are not required by end users.

Please do:

• try to adhere to the coding style of files you edit;
• comment code whose function or rationale is not obvious;
• update documentation (e.g., package.html files, hive-default.xml.template, this wiki, etc.)

Attaching and Submitting a Patch

...