Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Message-ID: <723862072.56511262733474877.JavaMail.jira@brutus.apache.org>
Date: Tue, 5 Jan 2010 23:17:54 +0000 (UTC)
From: "Kay Kay (JIRA)" <jira@apache.org>
To: hbase-dev@hadoop.apache.org
Subject: [jira] Commented: (HBASE-1433) Update hbase build to match core,
 use ivy, publish jars to maven repo, etc.
In-Reply-To: <1713437109.1242669525634.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HBASE-1433?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1279=
6906#action_12796906 ]=20

Kay Kay commented on HBASE-1433:
--------------------------------

{quote}
I agree with Ryan. Why should I have to bother with setting up some kind of=
 ivy proxy (locally?) ? The first thing I do with Hadoop 0.21 is build to p=
ull all the dependencies into build/ivy/.... and then copy them by hand int=
o a lib/ directory so I can put them on the Eclipse build path in a clean m=
anner. Any dependency changes, I have to fix them by hand. Before, SVN add/=
rm would handle that for me - the committer would deal with the dependency =
change. I'm not looking forward to needing to do the same thing for HBase.
My interest here is not to discourage this if people are generally in favor=
, but, personally, I prefer ant. I like make. I have a good relationship wi=
th Eclipse but otherwise IDEs get in the way. Etc. I see no personal benefi=
t for using ivy or maven, just an (unnecessary, IMO) learning curve, additi=
onal work if I need to fix something to get it to work for my changes, and =
a truckload of external dependencies.
{quote}

I find this thread interesting given that every other project in the eco-sy=
stem - hadoop-core / mapreduce / hdfs / mahout ( uses maven) / zookeeper (3=
.3.0+) go with a dependency manager in one form or the other.  It does not =
conflict with Eclipse in any way since instead of lib/** - people will be r=
equired to add build/ivy/common/** to the classpath .  SVN add/rm handling =
dependency management is definitely possible, but say in the case of lucene=
 - there are at least 6 different jars / contribs that are available and if=
 we want to flip between versions- adding and removing versions from source=
 control is not fun at all.  And with ivy - there is no need to install any=
 piece of software other than ant itself.   Version controlling snapshots o=
f projects will make it hard to keep up with their updates as and when they=
 become available and goes against the very objective of continuous build p=
rocess.  With this patch - people would be modifying ivy.xml / libraries.pr=
operties at max , without worrying about anything else and I find that way =
comfortable , compared to downloading yet another installation and version =
controlling them (and deleting old versions), not to mention deciding depen=
dency management winners.=20

> Update hbase build to match core, use ivy, publish jars to maven repo, et=
c.
> -------------------------------------------------------------------------=
--
>
>                 Key: HBASE-1433
>                 URL: https://issues.apache.org/jira/browse/HBASE-1433
>             Project: Hadoop HBase
>          Issue Type: Task
>    Affects Versions: 0.20.2
>            Reporter: stack
>             Fix For: 0.21.0
>
>         Attachments: HBASE-1433.patch, HBASE-1433.patch, HBASE-1433.patch=
, HBASE-1433.patch
>
>
> We are almost close, except for the republication of artifacts to mapredu=
ce snapshot repository from branch-0.21 (after applying the appropriate pat=
ch). It would be great to have this out for 0.21 .=20

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.