ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Dekany <>
Subject Chain resolver chaos with local dependency overrides
Date Sun, 08 Mar 2009 14:24:29 GMT
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

View raw message