[
https://issues.apache.org/jira/browse/IVY-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Hinds updated IVY-1333:
--------------------------------
Attachment: ErrorTest.zip
I don't think it's the same cause as IVY-1326 - when I run the test case
attached to that ticket, I don't see anything like
{code}
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]
{code}
I've attached an eclipse project which shows this error. Interestingly, while
trying to cut down the ivy files to the minimum configuration which triggers
this exception, I found that if I removed a custom attribute from the artifact,
the problem went away. In the attached zip file, if you remove the {{o:a}} and
{{xmlns:o}} attributes from {{badArtifact}}'s {{ivy.xml}}, no exception is
thrown. I would not expect unknown attributes to cause dependency resolution
errors.
Also in the test project is the hacked latest strategy which fixes this case.
> 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
>
>
> 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
