ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin (JIRA)" <j...@apache.org>
Subject [jira] Assigned: (IVY-694) cache dynamic revision resolution
Date Thu, 10 Jan 2008 14:37:33 GMT

     [ 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.


Mime
View raw message