ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicholas Hinds (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IVY-1333) Impossible to get artifacts when data has not been loaded for multiple dynamic revisions
Date Sat, 17 Mar 2012 02:22:38 GMT

     [ 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

        

Mime
View raw message