ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bord <>
Subject Re: help with TTL
Date Thu, 28 Jun 2012 14:32:53 GMT

Hey thanks Eyad,
Your reply had me reread the meaning of TTL at the ivy site and what you are
saying makes sense.
So, even though i have a TTL that just means i'm timing out reading from the
cache from a prior resolve.
But that then forces IVY to re-access repositories (and thus re-resolve as
from before).
But then i get the same result as before with my local repository "revision"
again having priority.
So, i'm basically just timing out the cache where I sorted of wanted to time
out the local repository org/mod/local_revision artifacts themselves or at
least not let them again have precedence.
Your suggestion on having "latest-time" as a strategy attribute is a bit in
the right direction.
I have to ensure that when i want a "3.0-r..." revision i dont instead
resolve to a later time "4.0-r..." revision.
Let me work with this some.
As you imply i might or might not be able to get what i want.
At worst our users might have to live with having to run a "clean-cache"
target to get rid of stale 3.0-rL (local repository) versions that are

Eyad Ebrahim wrote:
> It seems to be that the TTL is a cache attribute not a resolver one.
> Therefore, I don't think it will help your cause.
> I have a similar use case, I'm not sure if it would really help.
> You could take the latest version of both, won't that be helpful enough.
> It doesn't matter then the order in the chain, but all of them should have
> latest="latest-time" as a strategy attribute. Then from all the versions
> that comply with the artifact pattern would be checked and the newest one
> would be chosen.
> 1) The priority will be on date and on date only.
> 2) with cache checkmodified=true on resolvers you will presumably retrieve
> the very latest version of all (regardless local or remote).
> 3) I added the latest="latest-time" to the chain as well.
> If that is remotely related to what you need, I would be glad to help, if
> not. I'm glad to fill the world wide web to random stuff. it's my thing.
> On Wed, Jun 27, 2012 at 7:22 PM, bord <> wrote:
>> with apache ivy 2.2.0
>> would like to have two types of repositories.
>> an official one that publishes revisions  that look like 3.0-r456 (the
>> -rNNN
>> is a subversion rev value)
>> and a local one the publishes revisions that look like 3.0-rL (or
>> something
>> like this type of "changing" revision)
>> the local repository is to be in a  chain resolver ahead of the official
>> one
>> for "local" builds.
>> all our ivy.xml dependencies use a "dynamic" revision to resolve to for
>> matching: 3.0-r+
>> we seem to have trouble making the local published ivy/artifacts abide by
>> a
>> TTL value. i.e. we want to have local published stuff we able to timeout
>> after a couple days of inactivity.
>> but
>> every time we resolve in a local build we always get the 3.0-rL revision
>> from local repository even when TTL should have expired -- for eg 1ms
>>  <caches>
>>    <cache name="publicCache" basedir="${mse.ivy.cache.dir}">
>>      <ttl revision="3.0-r$L" duration="1ms" />
>>    </cache>
>>  </caches>
>> first we tried a changing revision for the local resolver:
>>  <filesystem name="local" checkmodified="true" changingPattern="3.0-rL"
>> changingMatcher="exact">
>> ...
>> </filesystem>
>> then we tried above without changingPattern and changingMatcher and did
>> not
>> help.
>> So, anyone know what it takes to do this?
>> --
>> View this message in context:
>> Sent from the ivy-user mailing list archive at

View this message in context:
Sent from the ivy-user mailing list archive at

View raw message