ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Oxenham (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IVY-1379) force attribute on resolver fails if module already in cache
Date Fri, 05 Oct 2012 05:18:47 GMT

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

Peter Oxenham updated IVY-1379:
-------------------------------

    Description: 
I have been struggling with getting the force="true" functionality to work and I now believe
there to be a bug.

Consider the scenario where:

A(1.0) > B(2.0) > C(1.1) 

and the resolver config is

chain -> filesystemLocal(force), resolverX


A resolve is performed and there is nothing in the local repo so the cache will then contain

A(1.0)
B(2.0)
C(1.1) 

Then a local version of C is published (local_1)

Performing a resolve at this point I would expect the following to be resolved
A(1.0)
B(2.0)
C(local_1) 

But instead the same three versions as above are resolved.

I have created a patch for 2.3.0_rc1 which includes a test to prove the problem.

Looking into the code the problem is due to the way the AbstractResolver determines the latest
in checkLatest(). When an existing version is found in the cache (in the above example C(1.1)),
then that version is compared with the revision found (in the second resolve above C(local_1)).
 Version 1.1 is the winner so it is returned.

There are a few scenarios where the force DOES work.  
1) When an existing version is not found in the cache. This is the case when the requested
version is a dynamic version OR the checkModified is set to true on the chain resolver
2) When the existing version is a 'default' one. This causes checkLatest() to return the newer
module. (this is why the patch includes an ivy.xml file for org1:mod1.2:2.0) 

  was:
I have been struggling with getting the force="true" functionality to work and I now believe
there to be a bug.

Consider the scenario where:

A(1.0) > B(2.0) > C(1.1) 

and the resolver config is

chain -> filesystemLocal(force), resolverX


A resolve is performed and there is nothing in the local repo so the cache will then contain

A(1.0)
B(2.0)
C(1.1) 

Then a local version of C is published (local_1)

Performing a resolve at this point I would expect the following to be resolved
A(1.0)
B(2.0)
C(local_1) 

But instead the same three versions as above are resolved.

I have created a patch for 2.3.0_rc1 which includes a test to prove the problem.

Looking into the code the problem is due to the way the chain resolver determines which 

    
> force attribute on resolver fails if module already in cache
> ------------------------------------------------------------
>
>                 Key: IVY-1379
>                 URL: https://issues.apache.org/jira/browse/IVY-1379
>             Project: Ivy
>          Issue Type: Bug
>    Affects Versions: 2.3.0-RC1
>            Reporter: Peter Oxenham
>         Attachments: ivy-2.3_force.patch
>
>
> I have been struggling with getting the force="true" functionality to work and I now
believe there to be a bug.
> Consider the scenario where:
> A(1.0) > B(2.0) > C(1.1) 
> and the resolver config is
> chain -> filesystemLocal(force), resolverX
> A resolve is performed and there is nothing in the local repo so the cache will then
contain 
> A(1.0)
> B(2.0)
> C(1.1) 
> Then a local version of C is published (local_1)
> Performing a resolve at this point I would expect the following to be resolved
> A(1.0)
> B(2.0)
> C(local_1) 
> But instead the same three versions as above are resolved.
> I have created a patch for 2.3.0_rc1 which includes a test to prove the problem.
> Looking into the code the problem is due to the way the AbstractResolver determines the
latest in checkLatest(). When an existing version is found in the cache (in the above example
C(1.1)), then that version is compared with the revision found (in the second resolve above
C(local_1)).  Version 1.1 is the winner so it is returned.
> There are a few scenarios where the force DOES work.  
> 1) When an existing version is not found in the cache. This is the case when the requested
version is a dynamic version OR the checkModified is set to true on the chain resolver
> 2) When the existing version is a 'default' one. This causes checkLatest() to return
the newer module. (this is why the patch includes an ivy.xml file for org1:mod1.2:2.0) 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message