On Tue, Mar 18, 2008 at 2:40 PM, Brown, Carlton < [EMAIL PROTECTED]> wrote:
> > -----Original Message----- > > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > > Sent: Monday, March 17, 2008 1:22 PM > > To: [email protected] > > Subject: Re: Does Ivy really have a cache resolver? > > > > CacheResolver has been introduced quite a long time ago and > > never documented because it wasn't supposed to be public. I'm > > still not sure it's a good idea to use it... IMO, Ivy caching > > mechanism should be strong enough to avoid the requirement > > for a cache resolver, at least at resolve time. With the > > addition of dynamic revisions caching in beta 2, now Ivy > > cache has all information necessary to be able to perform a > > resolve from the cache, without actually requiring to use the > > cache resolver. This may require some improvement, like > > accepting to use dynamic revision resolution cached data even > > when they have exceeded their TTL. This could be a special > > resolve mode or refresh mode. With this improvement, the last > > thing for which the cache resolver would still be useful is > > publishing. But even in this case, I'd prefer using a local > > repository with useOrigin="true": the behavior is sligthly > > different, but I think this should address all the needs > > covered by cache resolver which only has its root in bad > > caching support and is a design flaw. What do you think? Do > > you see a use case where CacheResolver is really necessary? > > Like you said, publishing is the situation where a CacheResolver is > really needed. It's true we can work around this by implementing a > local repository as our cache. But that duplicates artifact storage, > wastes disk space, etc. With useOrigin=true there's no duplication at all. Also we'd need to duplicate some sort of > cleaning strategy that already exists with <ivy:clean> Good point. But I find this cleaner to isolate cache (which you can always safely clean, since it should never have data that isn't available somewhere else) from repositories (which stores the actual data). In the case of an artifact you want only to share between two projects on the same box, one good answer may be to use directly the artifact where your project builds it, instead of having to publish it at all. > > > Considering that Ivy already has a perfectly good cache, it seems > inefficient and wasteful to duplicate that functionality. But I concede > that the local repo workaround is not too much of a hardship, and there > are more important issues to be worked right now. Agreed. Xavier > > > ----------------------------------------- > ==================================================== > This message contains PRIVILEGED and CONFIDENTIAL > information that is intended only for use by the > named recipient. If you are not the named recipient, > any disclosure, dissemination, or action based on > the contents of this message is prohibited. In such > case please notify us and destroy and delete all > copies of this transmission. Thank you. > ==================================================== > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
