hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Smith (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-2099) Move build to Maven
Date Sun, 07 Feb 2010 01:50:28 GMT

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

View raw message