You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by bord <bo...@iscp.telcordia.com> on 2012/06/27 19:22:25 UTC
help with TTL
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.
Re: help with TTL
Posted by bord <bo...@iscp.telcordia.com>.
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 <bo...@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.
Re: help with TTL
Posted by Eyad Ebrahim <ty...@gmail.com>.
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 <bo...@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.
>
>