[
https://issues.apache.org/jira/browse/IVY-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467280
]
Johan Stuyts commented on IVY-389:
----------------------------------
I think I found the problem: ChainResolver does not check the cache but leaves
that to the child resolvers. A child resolver will only return an item from the
cache if the item is resolved by itself.
I want to extend ChainResolver so it checks the cache before resolving the
dependency using its child resolvers. The issue I am facing is: when is
ChainResolver allowed to use the cache, and when must it resolve the dependency
using its child resolvers?
To make sure the solution will not break anything I think the following
assertions must hold:
- if the cache check is added to ChainResolver, it does not matter from which
resolver the dependency in the cache came from. i.e. ChainResolver will return
a dependency from any resolver from the cache.
- The 'returnFirst' option of ChainResolver does not influence the decision to
use the cache or to use the child resolvers. 'returnFirst' only applies if the
decision is made to search the child resolvers.
- ChainResolver is allowed to check the cache if all of the following
conditions are satisfied:
- the revision ID of the dependency is not dynamic.
- The revision ID of the module is not changing (the changing matcher is
not used at all in ChainResolver currently).
- ChainResolver has 'checkmodified' set to 'false' (this option is not
supported by ChainResolver currently).
Are the assertions above correct and is nothing missing?
> Detection of newer and better artifacts should not happen if 'checkModified'
> is set to 'false'
> ----------------------------------------------------------------------------------------------
>
> Key: IVY-389
> URL: https://issues.apache.org/jira/browse/IVY-389
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.4.1
> Reporter: Johan Stuyts
> Priority: Minor
>
> With 'checkModified' set to 'false' Ivy still looks for an artifact in
> repositories when there is a copy of the artifact in the cache. The
> repositories that are searched are the ones that are specified before the
> repository from which the copy in the cache was retrieved. The latter is not
> contacted.
> The above happens when 'returnFirst' is set to 'true' on the chain of
> repositories.
> Here is some example output from a build:
> local: no ivy file nor artifact found for [ javax.jdo | jdo2-api | 2.0 ]
> tried
> C:\home\jstuyts\data\ivy\hippo-open-source\local/javax.jdo/jdo2-api/2.0/ivy-2.0.xml
> tried
> C:\home\jstuyts\data\ivy\hippo-open-source\local/javax.jdo/jdo2-api/2.0/jdo2-api-2.0.jar
> CLIENT ERROR: Not Found
> url=http://repository.hippocms.org/ivy/javax.jdo/jdo2-api/2.0/ivy-2.0.xml
> CLIENT ERROR: Not Found
> url=http://repository.hippocms.org/ivy/javax.jdo/jdo2-api/2.0/jdo2-api-2.0.jar
> hipporep: no ivy file nor artifact found for [ javax.jdo | jdo2-api |
> 2.0 ]
> tried
> http://repository.hippocms.org/ivy/javax.jdo/jdo2-api/2.0/ivy-2.0.xml
> tried
> http://repository.hippocms.org/ivy/javax.jdo/jdo2-api/2.0/jdo2-api-2.0.jar
> hippomavenrep: revision in cache: [ javax.jdo | jdo2-api | 2.0 ]
> found [ javax.jdo | jdo2-api | 2.0 ] in hippomavenrep
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
