I have a chain-resolver that contains a filesystem-resolver and an
url-resolver. The filesystem-resolver is local to the developer's
workstation, while the url-resolver points to a webserver that is
common for all developers. Normally, Ivy just grabs all dependencies
from the webserver, but sometimes a developer wants to play locally
with a bleeding edge version of a *dependency* (which is not yet on
the webserver), so he publishes that with the filesystem-resolver, so
only on his workstation Ivy will use that from then. So far so good...
The problem is with using the version on the webserver again. I tried
two approaches:
(a) Ivy should always check both repositories, and chose the version
of the module that is the latest. With a chain and the default
returnFirst="false" this works as far as the revision "number" of
the older and newer stuff differs, but if only the publication
date differs (like for two snapshots) Ivy always chooses the
revision returned by the earlier resolver of the chain. It does
so despite <dependency ... changing="true" />. I checked that Ivy
downloads and parses the ivy.xml-s from both Ivy repositories, and
that both XML contains correct <info publication="...">, yet Ivy
always says that the one downloaded last was the older. That's
despite that from the publication attributes it's obvious that it
isn't so. Bug?
(b) After (a) failed, I decided that the filesystem-resolver will have
priority over the url-resolver (i.e., returnFirst="true"), and I
add an Ant task for un-publishing from the filesystem-resolver.
(This last is needed for (a) too anyway.) First of all, there is
no ivy:unpublish. Luckily I defined and control the
filesystem-resolver, so I know what to ant-<delete>, so this part
is worked around in this case. The problem is, after deleting from
the filesystem-resolver, Ivy still find the module there through
the cache. Shouldn't <dependency ... changing="true" />
effectively bypass the cache? I checked it, and it kind of did.
Ivy tries to open the files in the repository, and it realizes
they are not there anymore. But then instead of continuing with
the next resolver in the chain, it uses the cached copy of those
files that it *knows* to be non-existent. I mean, a cache should
reflect what it caches as precisely as it can, as far as it
doesn't defeat the performance, and in this case the
performance-defeating slow I/O was already done, so why the cache
doesn't reflex the new situation? Bug?
And, the point... I guess I try to address a fairly common use-case
here. What solution you guys use for this? (I try to rely on
ivy:cachepath instead of ivy:retrieve.)
--
Best regards,
Daniel Dekany
