Uploaded image for project: 'Ivy'
  1. Ivy
  2. IVY-1399

impossible to get artifacts when data has not been loaded.

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 2.3.0-RC2
    • 2.4.0
    • None
    • None

    Description

      I am getting the error "impossible to get artifacts when data has not been loaded. IvyNode = com.google.guava#guava;r08"

      This is happening with ivy 2.3.0-RC2.

      I am unsure what the best information to provide is, so here is the verbose output as well as ivy.xml

      https://gist.github.com/ebc2b325d333b739d0b1

      Attachments

        1. 0001-fix-IVY-1399.patch
          18 kB
          David Turner

        Activity

          madjack Jack Frosch added a comment - - edited

          I was getting the same with ivy-2.3.0-rc2.jar for all of these dependencies:

          org.apache.ant : ant : 1.8.4
          ant-contrib : cpptasks : 1.0b5
          org.apache.ivy : ivy : 2.3.0

          (I'm using the abbreviated Gradle notation for brevity, which I personally prefer to the # and ; separators used by Ivy. However, I'm not using Gradle on this project.)

          The specific error was: impossible to get artifacts when data has not been loaded. IvyNode = xerces#xercesImpl;2.8.1

          I do have a primary dependency declared for xerces though:

          xerces : xercesImpl : 2.10.0

          So I updated to using ivy-2.3.0.jar. The error was fixed for the ant and ivy dependencies, but still occurs if ant-contrib : cpptasks : 1.0b5 is declared as a dependency.

          –
          jack

          madjack Jack Frosch added a comment - - edited I was getting the same with ivy-2.3.0-rc2.jar for all of these dependencies: org.apache.ant : ant : 1.8.4 ant-contrib : cpptasks : 1.0b5 org.apache.ivy : ivy : 2.3.0 (I'm using the abbreviated Gradle notation for brevity, which I personally prefer to the # and ; separators used by Ivy. However, I'm not using Gradle on this project.) The specific error was: impossible to get artifacts when data has not been loaded. IvyNode = xerces#xercesImpl;2.8.1 I do have a primary dependency declared for xerces though: xerces : xercesImpl : 2.10.0 So I updated to using ivy-2.3.0.jar. The error was fixed for the ant and ivy dependencies, but still occurs if ant-contrib : cpptasks : 1.0b5 is declared as a dependency. – jack
          madjack Jack Frosch added a comment -

          Pardon my comment on my comment ...

          I found that I had made my build-support configuration extend my compile configuration, which included the xercesImpl-2.10.0.jar. When I changed the build-support configuration to not extend compile, the error didn't manifest. So the issue seems to be related to Ivy's handling of the conflict of the two xercesImpl dependencies, my primary dependency of xercesImpl-2.10.0.jar and cpptasks-1.0b5's transitive dependency on xerciesImpl-2.8.1.jar.

          I hope this is helpful.

          madjack Jack Frosch added a comment - Pardon my comment on my comment ... I found that I had made my build-support configuration extend my compile configuration, which included the xercesImpl-2.10.0.jar. When I changed the build-support configuration to not extend compile, the error didn't manifest. So the issue seems to be related to Ivy's handling of the conflict of the two xercesImpl dependencies, my primary dependency of xercesImpl-2.10.0.jar and cpptasks-1.0b5's transitive dependency on xerciesImpl-2.8.1.jar. I hope this is helpful.
          dturner-tw David Turner added a comment -

          I have another one of these: https://gist.github.com/anonymous/11159231

          I've attached a log and the (probably useless, since it contains two Twitter-internal deps) ivy XML file. The dependency chain that triggers the problem is:

          com.twitter.scalding_internal#job;0.0.2 requires org.slf4j#slf4j-api;1.6.1 while cascading#cascading-local;2.5.2
          requires org.slf4j#slf4j-api;1.7.2. job depends on dal, and dal depends on cascading-local.

          Note that an ivy.xml file which contains just job doesn't trigger the bug. Not sure why.

          The ivy.xml file I was using, however, includes a second dependency, com.twitter.scalding_internal#analytics-batch. Because
          analytics-batch doesn't require any particular version of slf4j-api, and because its dependencies include 1.7.2, 1.7.2 is chosen (I think).

          However, at this point, it's too late. 1.7.2 has already been "evicted" and thus its data never got loaded. So, we crash. We can
          confirm that this is the issue by swapping the order of the two dependencies; this fixes the crash.

          Hope this helps.

          dturner-tw David Turner added a comment - I have another one of these: https://gist.github.com/anonymous/11159231 I've attached a log and the (probably useless, since it contains two Twitter-internal deps) ivy XML file. The dependency chain that triggers the problem is: com.twitter.scalding_internal#job;0.0.2 requires org.slf4j#slf4j-api;1.6.1 while cascading#cascading-local;2.5.2 requires org.slf4j#slf4j-api;1.7.2. job depends on dal, and dal depends on cascading-local. Note that an ivy.xml file which contains just job doesn't trigger the bug. Not sure why. The ivy.xml file I was using, however, includes a second dependency, com.twitter.scalding_internal#analytics-batch. Because analytics-batch doesn't require any particular version of slf4j-api, and because its dependencies include 1.7.2, 1.7.2 is chosen (I think). However, at this point, it's too late. 1.7.2 has already been "evicted" and thus its data never got loaded. So, we crash. We can confirm that this is the issue by swapping the order of the two dependencies; this fixes the crash. Hope this helps.
          dturner-tw David Turner added a comment -

          This patch (against svn trunk) fixes the problem. I am not 100% sure it fixes it the correct way, but all of the test-cases still pass, and I included a test-case for this bug.

          I did this work as an employee of Twitter, and Apache has a CLA on file for Twitter.

          dturner-tw David Turner added a comment - This patch (against svn trunk) fixes the problem. I am not 100% sure it fixes it the correct way, but all of the test-cases still pass, and I included a test-case for this bug. I did this work as an employee of Twitter, and Apache has a CLA on file for Twitter.

          Patch submitted, thanks.

          antoine@apache.org Antoine Levy-Lambert added a comment - Patch submitted, thanks.

          You may want to build ivy from trunk to crosscheck that it works for you

          antoine@apache.org Antoine Levy-Lambert added a comment - You may want to build ivy from trunk to crosscheck that it works for you
          dturner-tw David Turner added a comment -

          Works great, thanks! When it's convenient, I would love to see a new RC release so we could peg Pants (our free/open source build tool that uses Ivy) to it.

          dturner-tw David Turner added a comment - Works great, thanks! When it's convenient, I would love to see a new RC release so we could peg Pants (our free/open source build tool that uses Ivy) to it.

          People

            Unassigned Unassigned
            carllerche Carl Lerche
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: