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


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.

Reply via email to