Mailing-List: contact notifications-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ant.apache.org
Date: Sun, 6 Sep 2015 12:16:45 +0000 (UTC)
From: =?utf-8?Q?Nicolas_Lalev=C3=A9e_=28JIRA=29?= <jira@apache.org>
To: notifications@ant.apache.org
Message-ID: <JIRA.12664272.1376862287000.266813.1441541805657@Atlassian.JIRA>
In-Reply-To: <JIRA.12664272.1376862287000@Atlassian.JIRA>
References: <JIRA.12664272.1376862287000@Atlassian.JIRA>
 <JIRA.12664272.1376862287797@arcas>
Subject: [jira] [Resolved] (IVY-1430) dynamic revisions are not cached per
 resolver
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


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

Nicolas Lalev=C3=A9e resolved IVY-1430.
----------------------------------
       Resolution: Fixed
         Assignee: Nicolas Lalev=C3=A9e
    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=C3=A9e
>              Labels: patch
>             Fix For: master
>
>         Attachments: 1430.diff
>
>
> If using a chain resolver, it is likely that dynamic revisions found in m=
ultiple child resolvers with thrash each other and negate the affect of usi=
ng 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=3Dintegration=3D1.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=3D1.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 =3D=
 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 m=
eans to them.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)