[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ivy-user
Subject:    Re: Confusion over latest integration resolution
From:       David Harrigan <dharrigan () gmail ! com>
Date:       2010-09-27 18:02:50
Message-ID: AANLkTin4cTfu1h5m8H4P9YvA7v1XiiH7wpqd1vO6NCPO () mail ! gmail ! com
[Download RAW message or body]

Hi,

Just out of curiosity, what is the order of your resolvers?

Mine is:

local

shared

releases

everything else

-=david=-

On 27 September 2010 16:45, Steve Miller <thatguy1177@gmail.com> wrote:
> Sounds like you're on the right track for sure.
>
> As far as resolvers go, I have been using returnFirst=true.  If I
> publish something in my local repo, I always want ivy to use that.
> When I'm done developing locally, I clear out my local repo so that
> the shared repo is used. It doesn't hurt to do it the way your doing
> it, assuming ivy can figure out the latest, but it may decrease
> performance of the resolve task.
>
> Steve
>
> On Mon, Sep 27, 2010 at 11:39 AM, David Harrigan <dharrigan@gmail.com> wrote:
>> Hi All,
>>
>> Thanks to everyone who replied :-)
>>
>> (Yes Steve, it is as you say - after a bit of experimentation I
>> understand it now)
>>
>> I have something working now, this is my setup (btw, using artifactory
>> which rocks):
>>
>> Module A:
>> module.version=0.1.0-SNAPSHOT
>>
>> When I build my jar, a fubar.jar is created in my dist directory. When
>> I publish to
>> artifactory (libs-snaphots-local), it goes in as fubar-0.1.0-SNAPSHOT.jar.
>>
>> Module B:
>> In my ivy.xml, I have declared a dependency on fubar as rev="latest.integration"
>> which pulls down from artifactory version 0.1.0-SNAPSHOT (or whatever it is).
>>
>> Whenever I do a new build of Module A, I keep the version to be 0.1.0-SNAPSHOT,
>> but the great thing is when I publish it, the date has changed so when I ask
>> Module B to do a resolve for me, it pulls down the latest from artifactory.
>>
>> If I now do this:
>>
>> ant -Dmodule.version=0.1.0 ivy.publish.release
>>
>> Module A goes into the libs-releases-local of artifactory.
>>
>> Now in my Module B ivy.xml, I change the rev from latest.integration to
>> 0.1.0 and when ivy does a resolve in Module B it pulls down the release
>> version.
>>
>> Neato.
>>
>> I like the fact that I can control the version numbers myself which is good.
>>
>> I think I understand it now, would I be on the right track?
>>
>> My last question I have now is local artifacts verses remote artifacts.
>>
>> Say I am working on Module A. Doing some code changes. I publish
>> locally my snapshot (say 0.2.0-SNAPSHOT). In my Module B, I have
>> changed the dependency on Module A revision from 0.1.0 now to
>> latest.integration.
>>
>> I remove the value "returnFirst" from my chain and indeed when I do
>> a resolve on Module B, ivy installs Module A 0.2.0-SNAPSHOT into
>> my Module B libs directory.
>>
>> My question is this:
>>
>> Is it correct to leave of returnFirst so that it forces Ivy to examine all
>> of the configured resolvers to correctly compare comparisons?
>>
>> I feel that everything seems to be working well, just looking for some
>> assurance that what I've done is accepted good practice and I'm not
>> leaving anything out.
>>
>> Thank you again one and all, it's been a very helpful few hours :-)
>>
>> -=david=-
>>
>>
>> On 27 September 2010 14:33, Steve Miller <thatguy1177@gmail.com> wrote:
>>> Actually, the jar will probably be named fubar.jar before you publish
>>> it. Then the publish ant task would have a revision of 1.0-SNAPSHOT,
>>> so when it's published, the jar would then be fubar-1.0-SNAPSHOT.jar
>>> in your repository (depending on your repository pattern).
>>>
>>> On Mon, Sep 27, 2010 at 7:03 AM, David Harrigan <dharrigan@gmail.com> wrote:
>>>> I see, so, if I put something like:
>>>>
>>>> fubar-1.0-SNAPSHOT.jar
>>>>
>>>> at the end of my jar and publish that, ivy should (after a bit of
>>>> further tweaking) pick up on that?
>>>>
>>>> I'll give it a whirl later and let you all know. Thanks all for your replies.
>>>>
>>>> -=david=-
>>>>
>>>> On 26 September 2010 16:34, Mitch Gitman <mgitman@gmail.com> wrote:
>>>>> This is something I stumbled on myself, but depending on
>>>>> "latest.integration" actually resolves a module with a status of integration
>>>>> OR GREATER. So, using the default set of statuses, "latest.integration" will
>>>>> get the latest module, whether its status is release or milestone or
>>>>> integration.
>>>>>
>>>>> The default status is integration if you don't specify one for ivy:deliver
>>>>> or ivy:publish. The documentation refers to an ivy.status property when it
>>>>> comes to how ivy:deliver/ivy:publish defaults the status but doesn't mention
>>>>> what that property's own default value is. There is an ivy.status.default
>>>>> property as well.
>>>>>
>>>>> On Sun, Sep 26, 2010 at 8:01 AM, James Davis <james.davis@atsid.com> wrote:
>>>>>
>>>>>> Additionally, the status of the artifact may need to be set to integration.
>>>>>>  As I understand it, latest integration pulls the latest version of an
>>>>>> artifact that has a status of integration.  However, I am not sure what the
>>>>>> default module status is though (have not looked at the docs to confirm).
>>>>>>
>>>>>> James Davis • QA Engineer II/Software Engineer
>>>>>> Applied Technical Systems, Inc. • Systems Division
>>>>>> web: www.atsid.com • e-mail: james.davis@atsid.com
>>>>>> (p) 360.698.7100 x241 • (f) 360.698.7200
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> I prefer encrypted and signed messages. KeyID: B20A22F9
>>>> Fingerprint: 110A F423 3647 54E2 880F ADAD 1C52 85BF B20A 22F9
>>>>
>>>
>>
>>
>>
>> --
>> I prefer encrypted and signed messages. KeyID: B20A22F9
>> Fingerprint: 110A F423 3647 54E2 880F ADAD 1C52 85BF B20A 22F9
>>
>



-- 
I prefer encrypted and signed messages. KeyID: B20A22F9
Fingerprint: 110A F423 3647 54E2 880F ADAD 1C52 85BF B20A 22F9

[prev in list] [next in list] [prev in thread] [next in thread]