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

List:       ivy-user
Subject:    =?UTF-8?Q?checkmodified=3D=E2=80=9Dtrue=E2=80=9D_on_a_chain_resolver=E2=80=99s_chi?=
From:       Mitch Gitman <mgitman () gmail ! com>
Date:       2010-09-06 0:23:40
Message-ID: AANLkTimmD3tXpcm36jM=M+s2ttFATi3nrxYvWot3Xuco () mail ! gmail ! com
[Download RAW message or body]


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.


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