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

Reply via email to