Ivy
  1. Ivy
  2. IVY-1333

Impossible to get artifacts when data has not been loaded for multiple dynamic revisions

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.0
    • Fix Version/s: 2.3.0-RC1
    • Component/s: None
    • Labels:
      None

      Description

      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:

      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)
      

      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:

      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

      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.

      loadData of rev#artifact;1.0.0.m4 of rootConf=dist
      dist is evicted. Skip loading

      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.

      1. anterror.zip
        4 kB
        Nicholas Hinds
      2. ErrorTest.zip
        6 kB
        Nicholas Hinds
      3. MaybeFixedLatestRevisionStrategy.java
        2 kB
        Nicholas Hinds

        Activity

        Hide
        Carl Quinn added a comment -

        We are seeing this exception as well, and it seems similar to IVY-1326 .

        Nicholas: I'd be interested in trying out your hacked LatestRevisionStrategy if you still have it handy. Maybe you could attach it to this jira.

        Show
        Carl Quinn added a comment - We are seeing this exception as well, and it seems similar to IVY-1326 . Nicholas: I'd be interested in trying out your hacked LatestRevisionStrategy if you still have it handy. Maybe you could attach it to this jira.
        Hide
        Nicholas Hinds added a comment -

        I don't have access to the original fix (or the case which caused this error) at the moment, but the attached MaybeFixedLatestRevisionStrategy.java should be roughly equivalent. I have not tested this file.

        Show
        Nicholas Hinds added a comment - I don't have access to the original fix (or the case which caused this error) at the moment, but the attached MaybeFixedLatestRevisionStrategy.java should be roughly equivalent. I have not tested this file.
        Hide
        Carl Quinn added a comment -

        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?

        Show
        Carl Quinn added a comment - 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 ?
        Hide
        Nicholas Hinds added a comment -

        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

        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]
        

        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.

        Show
        Nicholas Hinds added a comment - 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 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] 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.
        Hide
        Maarten Coene added a comment -

        Could you also attach your ivy.xml (and preferably a build.xml) to this issue so we could reproduce the problem more easily?

        Show
        Maarten Coene added a comment - Could you also attach your ivy.xml (and preferably a build.xml) to this issue so we could reproduce the problem more easily?
        Hide
        Nicholas Hinds added a comment -

        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)

        Show
        Nicholas Hinds added a comment - 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)
        Hide
        Maarten Coene added a comment -

        I've committed a fix for this issue in svn trunk.
        Could you give it a try and post your feedback here?

        thanks!
        Maarten

        Show
        Maarten Coene added a comment - I've committed a fix for this issue in svn trunk. Could you give it a try and post your feedback here? thanks! Maarten
        Hide
        Nicholas Hinds added a comment -

        The latest snapshot build has fixed the original problem. Thanks

        Show
        Nicholas Hinds added a comment - The latest snapshot build has fixed the original problem. Thanks

          People

          • Assignee:
            Maarten Coene
            Reporter:
            Nicholas Hinds
          • Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development