You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by "Xavier Hanin (JIRA)" <ji...@apache.org> on 2008/01/05 17:53:33 UTC
[jira] Created: (IVY-694) cache dynamic revision resolution
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.
[jira] Commented: (IVY-694) cache dynamic revision resolution
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557806#action_12557806 ]
Xavier Hanin commented on IVY-694:
----------------------------------
I've made good progress on this issue, Ivy now supports caching of dynamic revisions. In the code I've just checked in, it's even the default to cache resolved revisions for one hour. I'm not sure of this choice though, for backward compatibility we should better don't use this as the default. Or maybe if we implement finer grain TTL (for the moment you can only set the default TTL per cache), we could also give several defaults: no caching for latest.integration, one hour caching for other dynamic revisions for example. But this would be also more difficult to understand for users.
This is open for discussion, any comment would be appreciated.
> 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.
[jira] Resolved: (IVY-694) cache dynamic revision resolution
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Xavier Hanin resolved IVY-694.
------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0-beta-2
Without further comment on the issue, I mark this as resolved. Feel free to open other issues for improvements.
> 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
> Fix For: 2.0.0-beta-2
>
>
> 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.
[jira] Assigned: (IVY-694) cache dynamic revision resolution
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ 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.