[
https://issues.apache.org/jira/browse/HBASE-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830606#action_12830606
]
Paul Smith commented on HBASE-2099:
-----------------------------------
I'd 'vote' in favour of o.a.hbase as a groupId. If there is plans for HBase
to become a top-level project (and it makes sense), it probably should have
it's own identity independent of Hadoop.
You can then still choose to have an artifactid of hbase, I think that's fine
for now. Really it's about an artifacts identity. At some point though you
will probably (at least I hope you do) consider refactoring out independent
layers of Hbase. I think a 'hbase-client' jar for example is a great idea for
those apps that are just connecting scanner/update clients. Choosing 'hbase'
as an artifactId now doesn't preclude that down the track, I just think it
would be better to do it now, because later on if you want to do this right,
you(we) should consider a backwards compatibility layer.
For an example of how to 'migrate' groupId/artifactId definitions, see
http://maven.apache.org/pom.html#Relocation.
But it's probably nice to get it right first time. We over at log4j had a bit
of a newbie-maven-fail moment in log4j 1.2.15 with the jms/jmx dependencies,
because they were not declared as 'optional' upstream, so people have been
constantly adding the exclusions (hbase itself is a victim here.. :) )
> 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.
