[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ivy-user
Subject:    Re: defaultCacheDir="Dev/Null" ?
From:       Richard_Senior <richard.senior () gmail ! com>
Date:       2011-06-20 9:54:00
Message-ID: 31884229.post () talk ! nabble ! com
[Download RAW message or body]




Geoff Clitheroe-2 wrote:
> 
> If you're able to use dynamic revisions and come up with a suitable
> matching rule for artifacts from that repo then you could set a TTL
> rule with time 0
> 
> http://ant.apache.org/ivy/history/latest-milestone/settings/caches/ttl.html
> 
> Cheers,
> Geoff
> 

Thanks. I'm not using Dynamic revisions for various reasons.
I have found a solution which is simply to put the defaultCacheDir in a
location which is wiped at the beginning of every build. Obviously it occurs
to me that you must always have a valid resolution cache for the duration of
the retrieve at the very least or Ivy cannot function. This means that
setting defaultCacheDir to dev/null isn't a good idea anyway.

I have a separately defined cache in a more permanent place into which
resolvers that retrieve more permanent artifacts can cache.
I also have a resolver which is used for publishing and that is in a more
permanent place.
So my build first wipes the cache (I could probably use the ivy ant task to
do this anyway) then ivy finds the permanent 3rd party libs in my permanent
cache.
Then it finds my previously published artifacts in my publishing resolver
and caches them locally (but that cache will be wiped before the next
retrieve, meaning artifacts I have published will always be got from the
resolver every time, afresh).

My continuous integration build operates in the same way, but uses
artifactory instead of a local file system resolver, and I have two separate
settings files depending upon whether the cruise target of my ant script is
called (by cruise) or my local build target is called (by a developer).

I think I have now got a workable Ivy solution, and a future task to
implement dynamic revisions and use the method you suggested (which is
clearly the way forwards) instead of the method I describe above.

Just as a note. I think it would be nice if someone implemented a key word
which can be used in the Resolvers cache parameter which caused IVY to
simply not cache items from that Resolver.
Something like cache="no-cache" etc.?
-- 
View this message in context: \
http://old.nabble.com/defaultCacheDir%3D%22Dev-Null%22---tp31868223p31884229.html \
Sent from the ivy-user mailing list archive at Nabble.com.


[prev in list] [next in list] [prev in thread] [next in thread]