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

Reply via email to