[
https://issues.apache.org/jira/browse/IVY-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Lalevée resolved IVY-1430.
----------------------------------
Resolution: Fixed
Assignee: Nicolas Lalevée
Fix Version/s: master
excellent patch, thank you. Sorry it got so long at being integrated.
> dynamic revisions are not cached per resolver
> ---------------------------------------------
>
> Key: IVY-1430
> URL: https://issues.apache.org/jira/browse/IVY-1430
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Affects Versions: master
> Reporter: Stephen Haberman
> Assignee: Nicolas Lalevée
> Labels: patch
> Fix For: master
>
> Attachments: 1430.diff
>
>
> If using a chain resolver, it is likely that dynamic revisions found in
> multiple child resolvers with thrash each other and negate the affect of
> using the cache.
> Currently, if a chain resolver has two children, r1 and r2, and is asked to
> resolve "latest.integration", the logic is:
> 1. Ask r1 if it can resolve latest.integration. It looks in the ivycache,
> finds nothing, so hits the network, and finds 1.1.
> 2. Ivy creates a ivydata-latest.integration.properties file to cache that
> latestion=integration=1.1 and that it came from r1.
> 3. Ask r2 if it can resolve latest.integration. It looks in the ivycache,
> finds the latest.integration=1.1, but the resolver for that is r1, so it must
> hit the network, and finds 1.0. It is not newer, so 1.1 stays in the cache.
> ...
> Basically, r2 is not given the chance to write "my latest.integration = 1.0"
> anywhere in the cache, so it must hit the network any time it's asked for
> latest.integration.
> Instead, both r1 and r2 should be able to cache what latest.integration means
> to them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
