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 <mgit...@gmail.com> 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 > = FAILS > > YES checkmodified=”true” in ivysettings.xml > + YES changing=”true” in ivy.xml > = WORKS > > NO checkmodified=”true” in ivysettings.xml > + YES changing=”true” in ivy.xml > = WORKS > > 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. >
