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
stale.
cheers
bord
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.
> HOWEVER,
> 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 <b...@iscp.telcordia.com> 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:
>> http://old.nabble.com/help-with-TTL-tp34081797p34081797.html
>> Sent from the ivy-user mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context:
http://old.nabble.com/help-with-TTL-tp34081797p34086544.html
Sent from the ivy-user mailing list archive at Nabble.com.
