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