[ 
https://issues.apache.org/jira/browse/HBASE-14876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15281252#comment-15281252
 ] 

Daniel Vimont commented on HBASE-14876:
---------------------------------------

I’ve always presumed that the standard usage of any of these archetypes would 
be along the lines of the following:

# User runs {{archetype:generate}} against the archetype of their choice, which 
generates a complete Maven project for them.
# They start up a local instance of HBase.
# They run {{mvn install}} (in their IDE or from command line) to 
build/test/install the project.
# They execute the sample code, and begin using it as an active learning tool 
(altering the code, then rebuilding and executing it as they please).

I’ve just come to the full realization that step 3 will NOT work if it is 
preceded by step 2. The testing phase of the install process will fail with a 
RuntimeException saying {{‘HMasterAddress already in use’}}.  Apparently a 
minicluster started up by the HBaseTestingUtility *cannot* run in an 
environment where a local instance of HBase is running, because both of them 
will go after the same default “master info port” (16010).

Since I don’t want there to be even the slightest of problems or frustrations 
for a newbie HBase user to encounter when using artifacts generated from these 
archetypes, I’d like to modify the Test* modules that utilize the 
HBaseTestingUtility (i.e. *all* of them) to set an alternate master info port 
as follows...

Replace the current instantiation of the utility:
{code}
private static final HBaseTestingUtility TEST_UTIL  = new HBaseTestingUtility();
{code}
with the following:
{code}
  private static final HBaseTestingUtility TEST_UTIL;
  static {
    Configuration conf = HBaseConfiguration.create();
    // following setting prevents 'HMasterAddress already in use' exception
    conf.setInt(HConstants.MASTER_INFO_PORT, 16060);
    TEST_UTIL = new HBaseTestingUtility(conf);
  }
{code}

Unless someone knows of a reason why this shouldn’t be done (or has an 
alternate suggestion for dealing with this), I guess I’ll create a new JIRA 
entry and provide a patch soon for both of the archetypes that are already in 
2.0.0.

> Provide maven archetypes
> ------------------------
>
>                 Key: HBASE-14876
>                 URL: https://issues.apache.org/jira/browse/HBASE-14876
>             Project: HBase
>          Issue Type: New Feature
>          Components: build, Usability
>    Affects Versions: 2.0.0
>            Reporter: Nick Dimiduk
>            Assignee: Daniel Vimont
>              Labels: beginner, maven
>         Attachments: HBASE-14876-v2.patch, HBASE-14876.patch, 
> archetype_prototype.zip, archetype_prototype02.zip, 
> archetype_shaded_prototype01.zip
>
>
> To help onboard new users, we should provide maven archetypes for hbase 
> client applications. Off the top of my head, we should have templates for
>  - hbase client application with all dependencies
>  - hbase client application using client-shaded jar
>  - mapreduce application with hbase as input and output (ie, copy table)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to