[
https://issues.apache.org/jira/browse/IVY-694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Hanin reassigned IVY-694:
--------------------------------
Assignee: Xavier Hanin
> cache dynamic revision resolution
> ---------------------------------
>
> Key: IVY-694
> URL: https://issues.apache.org/jira/browse/IVY-694
> Project: Ivy
> Issue Type: New Feature
> Components: Core
> Reporter: Xavier Hanin
> Assignee: Xavier Hanin
>
> Currently when one use dynamic revision like latest.integration, the
> resolution of which revision this actually refer to is done at each resolve.
> When using a slow resolver, it can be very troublesome, especially for
> revisions which don't change very often (think about using a version range
> only for revision compatibility while using a latest-compatible conflict
> manager).
> Adding an option to cache the resolution of a dynamic revision would be nice.
> Obviously we'd need a way to setup for how long the cached resolved revision
> should be trusted (similar to a TTL in DNS system). A parameter to force the
> refresh of all cached dynamic revisions would also be a nice option to make
> sure one can always easily ask Ivy to make a full resolve without cleaning
> the cache.
> Being able to define TTL per revision or module revision would be nice too.
> This would allow people to setup fine grain TTL depending on how their
> repository change. An alternative to implementing this fine grain TTL
> settings in the cache would be to use the flexibility of resolvers settings.
> Indeed one could configure two resolvers differing only by how the TTL of
> their cache is setup. Then by setting one resolver for some kind of revision
> and the other one for the other could make the trick. The problem with that
> is that Ivy would see it as different resolvers, which could lead to problem
> if you configure one resolver for latest.integration and another one for 1.0,
> when latest.integration is resolved to 1.0, Ivy would think it uses two
> different resolvers for the same physical module revision, which is strongly
> discouraged in the module rule set documentation because we actually don't
> know how it works. Hence it seems that allowing fine grain TTL settings in
> the cache would be better than trying to leverage fine grain resolver
> settings.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
