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 <[email protected]> > 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 > >
