Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Message-ID: <578871462.5081267527927326.JavaMail.jira@brutus.apache.org>
Date: Tue, 2 Mar 2010 11:05:27 +0000 (UTC)
From: "Steve Loughran (JIRA)" <jira@apache.org>
To: hbase-dev@hadoop.apache.org
Subject: [jira] Commented: (HBASE-2099) Move build to Maven
In-Reply-To: <1775415801.129551262986314353.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Steve Loughran commented on HBASE-2099:
---------------------------------------

No, the metadata is often getting worse. Old stuff stays the same, and if you look at things like commons-logging 1.1.1 its dependency graph includes now pulls in servlets 2.3 while v 1.0.4 didn't. 
http://mvnrepository.com/artifact/commons-logging/commons-logging/1.1.1
Whatever tool you use, treat the dependency data as a hint rather than something to blindly depend on. Better to explicitly pull in everything you need. And when you release, audit your metadata before you ship, as you aren't allowed to change it.

1. ~/.m2/repository ~/.maven/repository. For Ivy I'd go for ~/.ivy and ~/.ivy2. You can do a full rm -rf or just purge your artifact tree. Either way, good to do for clean builds, especially the release VM.

2. The issue is just that when your build process involves creating RPMs and scp-ing them to VMs that you ask the cloud infrastructure for as part of the test run you are on your own, whatever tooling you have to hand.

3. Yes. Like I said, I'm not taking sides, just emphasising risk. 


> 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-2099.13.patch, HBASE-2099.14.patch, mvn.out, 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.