You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by "Nicolas Lalevée (JIRA)" <ji...@apache.org> on 2015/08/30 18:54:45 UTC

[jira] [Updated] (IVY-1430) dynamic revisions are not cached per resolver

     [ https://issues.apache.org/jira/browse/IVY-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nicolas Lalevée updated IVY-1430:
---------------------------------
    Labels: patch  (was: )

> 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
>              Labels: patch
>         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)