[ 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)