[
https://issues.apache.org/jira/browse/IVY-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231720#comment-13231720
]
Carl Quinn commented on IVY-1333:
---------------------------------
This particular fix didn't seem to help my case. Same symptom, different root
cause I think.
It seems that in my case we've got some modules that added <exclude>s of
themselves to hack around some cycle problems while testing, and this then
causes downstream builds to break when they depend on those modules. Seems that
exclude masks the loading of the module and then the same check fails in
IvyInfo later.
Is this bug possibly related to: IVY-1326?
> 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: MaybeFixedLatestRevisionStrategy.java
>
>
> 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
