ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée (JIRA) <j...@apache.org>
Subject [jira] Commented: (IVYDE-186) Resolve in Workspace fails to find projects under certain conditions
Date Sun, 30 Aug 2009 10:23:32 GMT

    [ 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 "working@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.


Mime
View raw message