ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicholas Hinds (Created) (JIRA)" <j...@apache.org>
Subject [jira] [Created] (IVY-1333) Impossible to get artifacts when data has not been loaded for multiple dynamic revisions
Date Mon, 23 Jan 2012 21:53:40 GMT
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


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

        

Mime
View raw message