ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Scokart <gscok...@gmail.com>
Subject Re: Chain resolver chaos with local dependency overrides
Date Sun, 08 Mar 2009 19:06:21 GMT
I do somthing similar.  When a developper has finish to play with a local
dependency he must clean his local repository, clean his cache and
re-execute a resolve.
Not very nice, but in my context it seems to be OK (we rarely have to play
with local dependencies).


Gilles Scokart


2009/3/8 Daniel Dekany <ddekany@freemail.hu>

> 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
>
>

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