ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Miller <thatguy1...@gmail.com>
Subject Re: Confusion over latest integration resolution
Date Mon, 27 Sep 2010 15:45:53 GMT
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
>

Mime
View raw message