Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Received-SPF: pass (nike.apache.org: domain of kaykay.unique@gmail.com
 designates 209.85.217.228 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=YaSq0P2iQ86iEPFsBoAbTZ3mCsTMvRZbuu8jMRuHqDsojvZRYYB/wAXDhHgoYxaBbm
         gy2yHaXBUpAQAxh36kJdY0cVW1n8YKhM4y50tvpwPGapD9VrXX9MCvAJhFB6Gs/ZJ+01
         nC0n9BXnDveqvKh76eAgkdjE29HoFu8oFO7oo=
Message-ID: <4B46CC50.10009@gmail.com>
Date: Thu, 07 Jan 2010 22:10:24 -0800
From: Kay Kay <kaykay.unique@gmail.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: hbase-dev@hadoop.apache.org
Subject: Re: OK with all that build moves to use ivy resolving dependencies?
References: <7c962aed1001072030r2e88b371jed316acf46b34024@mail.gmail.com>
	 <31a243e71001072037y2da062dft779e1fdbf05906ac@mail.gmail.com>
	 <31a243e71001072037p31745010t190d24fcd18bd46c@mail.gmail.com>
	 <238155.37894.qm@web65514.mail.ac4.yahoo.com>
 <78568af11001072142k4014895dxfd330d2d5a3a11a5@mail.gmail.com>
In-Reply-To: <78568af11001072142k4014895dxfd330d2d5a3a11a5@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ryan Rawson wrote:
> I'm not a fan of systems that increase complexity for no major wins.
>   
I can bet , somebody else, bringing up dependency management in one form 
or another, soon (well- this was already a jira issue, before I started 
this thread ).

> After talking to some guys on #hbase, I think we'd be better off going
> to maven.
Can you be more specific, about some of the pros/ cons, that you think 
is applicable to hbase.
>  It's more complex, but you get more wins out of it.  It
> sounds like the contributor just wants maven published artifacts, so
> it's not even 'ivy' as per se.
>
> So given all that, I'd rather do the whole hog, rather than the half
> and half thing. Ie: maven over ivy.
>   
My original objective was to upgrade the Lucene version, for indexing 
from 2.2 ( pretty old ) to 3.x , where I needed to use some of the 
significant changes gone in 2.9 and some API sugar / performance 
improvements in 3.0+ .

I was under the assumption of flipping a version in properties and 
resubmitting a patch towards it, but later discovered the versioning of 
dependencies  (deleting + adding jars).

Chose ivy because it was used in core/mr/hdfs and thought that is the 
standard dependency management tool in the hadoop (+ family) world.

I have nothing against maven, but chose ivy only because it offers the 
best way to reuse investments in build.xml , made over a period of time 
and a comparatively easier learning curve (compared to mvn). My $ 0.02 .


> -ryan
>
>
> On Thu, Jan 7, 2010 at 9:35 PM, Andrew Purtell <apurtell@apache.org> wrote:
>   
>> +0
>>
>>     
>>> On Jan 7, 2010 8:30 PM, "stack"  wrote:
>>>       
>>> Unless there is objection, we'll commit hbase-1433 in the next day or so.
>>> This contribution by Kay Kay adds ivy (http://ant.apache.org/ivy/) to our
>>> build for resolving dependencies.  Whereas previous all dependencies were
>>> checked-in under $HBASE_HOME/lib, instead, ivy will pull from remote
>>> internet repositories all dependencies listed/needed by the hbase project on
>>> ant build (It keeps a local cache so pulls a dependency once-only).  The
>>> move to ivy realigns our build system with that of our parent hadoop -- it
>>> uses ivy resolving dependencies.  Ivy also has strong affinity to Maven and
>>> will make it easier for us publishing hbase builds up to a Maven repository,
>>> e.g. the Apache Maven repository (Our parent project currently does this).
>>>
>>> This ok with all?
>>> Thanks,
>>> St.Ack
>>>       
>>
>>
>>
>>
>>     
>
>