You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by "Peter Oxenham (JIRA)" <ji...@apache.org> on 2012/10/05 07:08:47 UTC
[jira] [Created] (IVY-1379) force attribute on resolver fails if
module already in cache
Peter Oxenham created IVY-1379:
----------------------------------
Summary: 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.
--
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
[jira] [Updated] (IVY-1379) force attribute on resolver fails if
module already in cache
Posted by "Peter Oxenham (JIRA)" <ji...@apache.org>.
[ 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 chain resolver determines which
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.
> 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 chain resolver determines which
--
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
[jira] [Updated] (IVY-1379) force attribute on resolver fails if
module already in cache
Posted by "Peter Oxenham (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (IVY-1379) force attribute on resolver fails if
module already in cache
Posted by "Peter Oxenham (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Oxenham updated IVY-1379:
-------------------------------
Attachment: ivy-2.3_force.patch
Patch that adds a test to prove the issue.
> 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.
--
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