[
https://issues.apache.org/jira/browse/IVYDE-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Lalevée updated IVYDE-186:
----------------------------------
Component/s: (was: classpath container)
workspace resolver
Fix Version/s: (was: 2.0.0.final)
I have added a workspace resolver component as you suggested. For the fix
version I have no time to look at your patch before the release of IvyDE
2.0.0-final so it will be postponed to the next one.
> 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: workspace resolver
> Affects Versions: 2.0.0.final
> Reporter: Adam Karl
> 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.
