hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From stack <st...@duboce.net>
Subject Re: OK with all that build moves to use ivy resolving dependencies?
Date Mon, 11 Jan 2010 00:57:40 GMT
I committed hbase-1443.  HBase TRUNK build is now ivy based.  On update,
you'll notice a leaner lib directory and on build, hbase  (ivy) will go to
the net to pull in hbase dependencies. Kay Kay has written up a useful Ivy
Primer, http://wiki.apache.org/hadoop/Hbase/IvyPrimer,  that you all might
want to take a look at.   Stick any questions here.

Thanks,
St.Ack


On Fri, Jan 8, 2010 at 1:33 PM, stack <stack@duboce.net> wrote:

> Good on you Ryan.
>
> I made hbase-2099 for discussion of moving hbase to maven (There is already
> HBASE-1403 on moving src/contribs out of hbase).
>
> Unless I get a -1 soon, I'll go ahead with the hbase-1433 commit.
>
> St.Ack
>
>
> On Thu, Jan 7, 2010 at 10:54 PM, Ryan Rawson <ryanobjc@gmail.com> wrote:
>
>> I'm ok with the ivy thing, I just wanted to raise the non-disconnected
>> build issue, since moving to ivy is not 'no cost' as proponents would
>> like to paper over. I just wanted to make sure everyone realizes this
>> will hurt productivity of some people.
>>
>> On Thu, Jan 7, 2010 at 10:52 PM, stack <stack@duboce.net> wrote:
>> > On Thu, Jan 7, 2010 at 9:42 PM, Ryan Rawson <ryanobjc@gmail.com> wrote:
>> >
>> >> So given all that, I'd rather do the whole hog, rather than the half
>> >> and half thing. Ie: maven over ivy.
>> >>
>> >
>> >
>> > I'm not opposed to a move to Maven. I've not really given it much
>> thought,
>> > but I think that a separate discussion and undertaking.  It would take
>> some
>> > work doing it properly.  We would need to take on the maven layout at a
>> > minimum -- move all to src/main/java, etc. -- and we'd need to purge any
>> > deviation from the maven way because the alternative is hours burnt
>> > wandering in the weeds of poorly documented plugin xml configs., or
>> worse,
>> > hours writing custom maven plugins to pull Maven in alternate
>> directions.
>> >  For one, our notion of contrib (src/contrib/*), IIRC, does not map to
>> > maven's notion of subprojects. Its been a while but with Maven
>> subprojects
>> > notion, you could not without backflips have the parent project build
>> its
>> > jar and then have subprojects depend on parent.
>> >
>> > If someone wants to take on the Maven work, well and good but for me the
>> Ivy
>> > work is done.  Lets commit it.  The way it does its dependencies is
>> > Maven-like (you list them in pom for maven, in properties for ivy; both
>> pull
>> > to local caches, etc.).  Committing Ivy gets us working with external
>> > repositories, pulling and publishing.  So, the ivy commit takes us some
>> of
>> > the ways toward a mavenized hbase while meantime, making hbase build
>> like
>> > its hosting project and its siblings.
>> >
>> > St.Ack
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message