[
https://issues.apache.org/jira/browse/IVYDE-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12726048#action_12726048
]
Adam Karl commented on IVYDE-186:
---------------------------------
There could probably also be a component added to Jira just for the workspace
resolver. It is a critical feature for the way that many people use/would use
IvyDE.
> Resolve in Workspace fails to find projects under certain conditions
> --------------------------------------------------------------------
>
> Key: IVYDE-186
> URL: https://issues.apache.org/jira/browse/IVYDE-186
> Project: IvyDE
> Issue Type: Bug
> Components: classpath container
> Affects Versions: 2.0.0.final
> Reporter: Adam Karl
> Fix For: 2.0.0.final
>
> Attachments: IVYDE-186-2.0.0-final
>
>
> Under certain conditions the resolve in workspace resolver fails to find the
> appropriate project to add into the classpath container. After stepping
> through the code I found a few potential problems.
> 1 - The workspace project may have a revision with the pattern
> "work...@workstation_name". At the same time the revision specified in the
> ivy.xml may have an explicit revision. In this case I would want my working
> copy to take precedence. When this is the case the default chain resolver
> falls through each of its child resolver checks since the specified revision
> is not dynamic for any of them. In effect, this makes the resolver only use
> "exact" which will fail. I have some doubts as to why the chain resolver
> does not use the "accept" method for each of its child resolvers but that is
> outside the scope of ivyde so my solution avoids the problem by wrapping
> whatever the default resolver is in a new chain resolver which falls through
> to a new abstract resolver looking specifically for "workstation@".
> 2 - If the project had been resolved previously to a cache location the
> cached jar in my case was taking precedence over the project. I stepped
> through this code and found that there is a comparison for the "default"
> attribute of a revision. I did not see usage elsewhere in the project of the
> default attribute so I simply set it to false for the generated module
> descriptor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
