[
https://issues.apache.org/jira/browse/HBASE-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799562#action_12799562
]
Paul Smith commented on HBASE-2099:
-----------------------------------
ok, I'm making more progress, I'm getting test failures, but then I think the
same tests fail when running through ivy, so perhaps a local environment thing,
for now I'm focusing on making the jars generated by ivy and by maven to be
identical. I do this by unpacking the ivy & maven generated ones into 2
different directories and then running the Mac's opendiff tool to look for
differences.
Heres some bits I've discovered so far.
* the ivy generated targets appear to 'fatten up' the jar with duplicate files
in different directories. For example hbase-default.xml:
{noformat}
bash-3.2$ unzip -l ../build/hbase-0.21.0-dev.jar | fgrep hbase-default.xml
21472 01-12-10 11:04 hbase-default.xml
21472 01-12-10 11:04 conf/hbase-default.xml
{noformat}
I can probably replicate that behaviour but it will make the Maven pom more
messy.
* Maven appears to locate some .java files from _within_ the zookeeper
dependency and decides to compile these to the hbase class output. That's
annoying, I haven't spotted this one before, I'll raise this with the Maven
crew.
* The ivy-generated jar contains pre-compiled JSP files:
{noformat}
bash-3.2$ unzip -l ../build/hbase-0.21.0-dev.jar | fgrep generated | fgrep -v
thrift
0 01-12-10 13:17 org/apache/hadoop/hbase/generated/
0 01-12-10 13:17 org/apache/hadoop/hbase/generated/master/
0 01-12-10 13:17 org/apache/hadoop/hbase/generated/regionserver/
12646 01-12-10 13:17
org/apache/hadoop/hbase/generated/master/master_jsp.class
13018 01-12-10 13:17
org/apache/hadoop/hbase/generated/master/table_jsp.class
4857 01-12-10 13:17
org/apache/hadoop/hbase/generated/master/zk_jsp.class
8833 01-12-10 13:17
org/apache/hadoop/hbase/generated/regionserver/regionserver_jsp.class
{noformat}
I know Hbase uses Jetty for it's runtime web -apps and I can see in build.xml
the jsp compilation, but whether the raw JSP's should be compiled and bundled
isn't clear (for the small # of them it doesn't really seem high value, simpler
for Jetty to compile dynamically at boot time?). Seems to overcomplicate the
build process?
I suspect this is just going to be much cleaner with some directory reshuffling.
i will keep pottering.
> 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: HBASE-2099.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.