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 Sat, 06 Feb 2010 10:12:28 GMT

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

Paul Smith commented on HBASE-2099:
-----------------------------------

Just replying to something stack said way back in response to the generated binary:

bq. We need to get test jar in there too.

No problem, just odd, not normally something that is bundled in a binary artifact (I don't
think I've every seen that).

bq. The resultant jar is named hbase-core

I've got the sources bundled as a jar inside the tar ball, and fixed the 'hbase-core' - 'hbase'
jar naming convention.   do wonder if in the longer term it would better to instead of change
the 'finalName' property in the pom to bypass the artifictId, instead rename the artifactId
to just be 'hbase' (so groupId:artifactId being org.apache.hadoop.hbase:hbase).  That might
make things overal simpler ?

I generated the ant/ivy generated binary with the latest trunk for comparison, oddly it currently
dosen't include sources, or test jars.  Maybe that's a fallout of the ivy transition?  

bq. The lib dir is a bit overpopulated methinks but would have to check

Yeah, compared with the one generated by ivy, it's a bit.. thicker.  Is zookeeper all we need
in the binary?  Easy to do, just odd that with the declared dependencies the transitive ones
are coming in too.  You guys should know from experience what exactly is needed to run this,
so I'm up for suggestions, I'll try to mimic the Ivy-generated format for now since that should
be what we're tracking against, it's just that if I look at my local hbase 0.20.1 binary install
I grabbed weeks ago for mucking around with there's 24 jars and 2 directories in the lib directory,
and that's way more than what is spitting out under ivy right now?

I'm going to package up the rest of the contrib projects next, that should be straight forward.




> 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 Move
Script.txt, HBASE-2099.7.patch, HBASE-2099.8.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.


Mime
View raw message