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