[ 
https://issues.apache.org/jira/browse/IVY-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250186#comment-13250186
 ] 

Nicholas Hinds commented on IVY-1333:
-------------------------------------

The latest snapshot build has fixed the original problem. Thanks :)
                
> Impossible to get artifacts when data has not been loaded for multiple 
> dynamic revisions
> ----------------------------------------------------------------------------------------
>
>                 Key: IVY-1333
>                 URL: https://issues.apache.org/jira/browse/IVY-1333
>             Project: Ivy
>          Issue Type: Bug
>    Affects Versions: 2.2.0
>            Reporter: Nicholas Hinds
>            Assignee: Maarten Coene
>             Fix For: 2.3.0-RC1
>
>         Attachments: ErrorTest.zip, MaybeFixedLatestRevisionStrategy.java, 
> anterror.zip
>
>
> When some transitive dependencies depend on the same artifact with the same 
> dynamic revision (say, "1.0.0.+"), and some depend on the actual latest 
> version (say, "1.0.0.m4"), sometimes it results in an IllegalStateException:
> {code}
> java.lang.IllegalStateException: impossible to get artifacts when data has 
> not been loaded. IvyNode = rev#artifact;1.0.0.m4
>       at org.apache.ivy.core.resolve.IvyNode.getArtifacts(IvyNode.java:762)
>       at 
> org.apache.ivy.core.resolve.IvyNode.getSelectedArtifacts(IvyNode.java:739)
>       at 
> org.apache.ivy.core.report.ResolveReport.setDependencies(ResolveReport.java:235)
>       at 
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:238)
>       at org.apache.ivy.Ivy.resolve(Ivy.java:512)
> {code}
> This exception is reproducable for a given combination of artifacts. Changing 
> the dependencies slightly so the module depends directly on a specific 
> version of the artifact seems to fix this problem, as does changing some of 
> the transitive dependencies.
> The issue seems to be caused by the {{LatestRevisionStrategy}} comparing two 
> IvyNodes as equal because they have the same resolved id, but their actual 
> IDs differ. The following debug log shows the conflict manager trying to 
> resolve the 1.0.0.+ and 1.0.0.m4 dependencies:
> {quote}
> found conflicting revisions for rev#artifact;1.0.0.m4 in 
> rev#another-artifact;1.0.0.beta: [rev#artifact;1.0.0.m4, 
> rev#artifact;1.0.0.m4]
> {quote}
> When the {{LatestRevisionStrategy}} is asked to pick the latest revision out 
> of those two artifacts, it just chooses the last one in the list (since they 
> compare as equal the order is maintained). At different points in the 
> resolve, the list is passed to the {{LatestRevisionStrategy}} in a different 
> order and a different artifact is considered the latest one, so both versions 
> end up being evicted.
> {quote}
> loadData of rev#artifact;1.0.0.m4 of rootConf=dist
> dist is evicted.  Skip loading
> {quote}
> The fix is to make the order deterministic when the resolved ids are equal 
> but unresolved ids are not. A simple hacky workaround is to try the regular 
> comparison, and if that doesn't work, try comparing the real revisions. This 
> seems hacky because the {{ArtifactInfo}} class doesn't provide any 
> information about the real revisions, only the resolved revisions. I have a 
> local hacked subclass of {{LatestRevisionStrategy}} which fixes this problem, 
> if it helps.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to