[
https://issues.apache.org/jira/browse/IVYDE-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749244#action_12749244
]
Nicolas Lalevée commented on IVYDE-186:
---------------------------------------
Could you more specific about the "certain conditions" you are talking about ?
I have tried different scenarios, and every of them works for me:
* project1 with no revision in ivy.xml, project2 depending on project1 rev="1.2"
* project1 with no revision in ivy.xml, project2 depending on project1
rev="latest.integration"
* project1 with revision="1.2" in ivy.xml, project2 depending on project1
rev="latest.integration"
* project1 with revision="1.2" in ivy.xml, project2 depending on project1
rev="1.2"
* project1 with revision="1.2" in ivy.xml, project2 depending on project1
rev="[1.1,1.3]"
> 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.
