ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brown, Carlton" <Carlton.Br...@compucredit.com>
Subject RE: Does Ivy really have a cache resolver?
Date Tue, 18 Mar 2008 13:40:56 GMT
 > -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com] 
> Sent: Monday, March 17, 2008 1:22 PM
> To: ivy-user@ant.apache.org
> 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.  Also we'd need to duplicate some sort of
cleaning strategy that already exists with <ivy:clean>

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.

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

Mime
View raw message