ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <>
Subject Re: checkmodified=”true” on a chain resolver’s child resolver
Date Tue, 14 Sep 2010 16:56:44 GMT
I’m very pleased to say… My bad.

I’ve managed to get checkmodified behaving exactly as I would expect it to
behave on a child resolver within a chain. Looks like there was some
weirdness about a test I was running.

On Sun, Sep 5, 2010 at 5:23 PM, Mitch Gitman <> wrote:

> I’m using Ivy 2.2.0-rc1. I have a filesystem resolver on which I’ve
> specified checkmodified=”true” so Ivy checks the timestamp. I want to place
> this resolver inside a chain resolver where the one other child resolver in
> the chain does trust the cache. Here’s what I want:
>     <chain name="local-chain-resolver">
>       <resolver ref="local-integration-resolver" /> <!--
> checkmodified=”true” -->
>       <resolver ref="local-release-resolver" />
>     </chain>
> I proceed to publish Ivy module A to the repository that will be consumed
> by local-integration-resolver. Then I go to build a project that depends on
> Ivy module A, but the changes to A are not picked up.
> Now, I’m sure someone will say something to the effect of: In your
> dependent project’s ivy.xml, go to the dependency on A and set
> changing=”true”. But this is precisely the thing I want to avoid doing.
> What’s more, suppose that I am specifying changing=”true”. Then the latest
> changes to A get picked up regardless of whether checkmodified=”true” is
> specified.
> Here’s what I found:
> YES checkmodified=”true” on local-integration-resolver in ivysettings.xml
> + NO changing=”true” in ivy.xml
> YES checkmodified=”true” in ivysettings.xml
> + YES changing=”true” in ivy.xml
> NO checkmodified=”true” in ivysettings.xml
> + YES changing=”true” in ivy.xml
> So the way Ivy is behaving for me, changing=”true” WORKS regardless of
> whether checkmodified=”true”, and changing=”true” IS NEEDED regardless of
> whether checkmodified=”true”. In other words, checkmodified=”true” doesn’t
> actually do anything when specified on the included resolver.
> Not knowing any better, I tried experimenting with specifying
> checkmodified=”true” on the chain resolver itself, even though semantically
> this doesn’t make sense and the documentation says this is not available on
> compound resolvers. (Even if this was supposed to work, I’d be wary of it
> because I want to make sure Ivy is trusting the cache for
> local-release-resolver.) Bizarrely, not only did Ivy not complain that I set
> checkmodified=”true” on the chain resolver, but this actually got things
> working, provided I specified a changingPattern and changingMatcher on the
> child resolver.
> One other observation. I was able to get this working if I specified the
> same changingPattern and changingMatcher on both the child integration
> resolver and the chain resolver (no checkmodified on the chain resolver).
> However, removing these two extra attributes from the integration resolver
> reintroduced the failure.
> Now, I suppose the next thing to do is to step through the code in debug
> mode. But this is one of those times where I have to take a step back for a
> moment and ask, “Am I crazy or what?” Chaining together an integration
> resolver and a release resolver while leveraging checkmodified is an
> integral feature of Ivy.

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