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