Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Message-ID: <1322168891.101901265499927949.JavaMail.jira@brutus.apache.org>
Date: Sat, 6 Feb 2010 23:45:27 +0000 (UTC)
From: "Kay Kay (JIRA)" <jira@apache.org>
To: hbase-dev@hadoop.apache.org
Subject: [jira] Commented: (HBASE-2099) Move build to Maven
In-Reply-To: <1775415801.129551262986314353.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Kay Kay commented on HBASE-2099:
--------------------------------

|  ... you think the above better than my suggestion of groupid org.apache.hadoop and our artifactid of hbase?

| Related, its a good ways of I think but there is talk of a few of the hadoop projects moving up to be top-level apache projects. HBase is probably a good candidate so our default package would become o.a.hbase at some stage in the future. This would seem to argue in favor of your suggestion for a groupid of o.a.h.h Kay Kay?

I guess - the way it works is , a project owns a groupId and can publish any number of artifacts as it sees fit ( and versions under the same). 

Since o.a.h is essentially owned by the hadoop project and I see HBase as an independent project , as you had mentioned yourself, hence thought it might be useful for us to reserve a groupId unique to HBase.

say - o.a.h.hbase   or o.a.hbase , but wanted to make the distinction between the groupId chosen by HBase and hadoop projects ( mapreduce/ hdfs/ common - etc.), all of which use o.a.h . 

This will give us the flexibility to publish artifacts as we see fit , under it without disturbing the groupId owned by other teams. 


As far as the jira being closed - I believe it was closed saying o.a.hadoop , already exists ( as requested initially).  For the sake of independence of the project, it might make sense to reopen with a different groupId like - o.a.h.hbase , or o.a.hbase , better. 

And then we can fit that groupId in this pom.xml . 


> Move build to Maven
> -------------------
>
>                 Key: HBASE-2099
>                 URL: https://issues.apache.org/jira/browse/HBASE-2099
>             Project: Hadoop HBase
>          Issue Type: Task
>            Reporter: stack
>         Attachments: findbugs.html, findbugs.html, HBase Move Script.txt, HBASE-2099.9.patch, test-reports.zip
>
>
> This issue is for discussing pros and cons of moving hbase build to Apache Maven.
> Maven, if you take on its paradigm, does a lot for you.  There are also a bunch of nice plugins that do nice reports on state of project; findbugs, that nice plugin where you can give out urls that will resolve to lines in source code (a doxygen-like thing ... I've forgotten its name).  Other examples are a docbook plugin that would do the build inline with doc build.  We could start up the hbase book using docbook format and the hbase book would ride along with versions.
> As I see it -- and its a while since I've done this stuff so things may have since changed -- in the way of an easy move to maven is our src/contrib content.  Maven would have these as distinct projects pulling in their hbase dependency or, if you wanted to take on the maven subproject notion, then, hbase would be at same level in build as the contribs -- it would be a subproject too just built before the others.
> Anyone interested in working on this issue?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.