[
https://issues.apache.org/jira/browse/IVYDE-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Lalevée resolved IVYDE-186.
-----------------------------------
Resolution: Fixed
Fix Version/s: 2.1.0
Assignee: Nicolas Lalevée
I didn't know why I wrote
bq. project1 with no revision in ivy.xml, project2 depending on project1
rev="1.2"
worked, but effectively it doesn't.
It is fixed in trunk, thanks for the patch.
> 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
> Assignee: Nicolas Lalevée
> Fix For: 2.1.0
>
> 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.
