[
https://issues.apache.org/jira/browse/IVY-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Hinds updated IVY-1333:
--------------------------------
Attachment: anterror.zip
Sure thing, I've converted the eclipse project which reproduced it into an ant
project in the attached anterror.zip.
Running {{ant}} or {{ant ivyerror}} will reproduce the problem. Running {{ant
ivyfixed}} will do the same resolve but with the modified latest revision
strategy, which should succeed (if you've got the attached class on your
classpath)
> 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
> 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
