Ivy
  1. Ivy
  2. IVY-1178

Transitive dependencies resolutions issue when eviction is triggered

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1.0
    • Fix Version/s: 2.2.0-RC1
    • Component/s: Core
    • Labels:
    • Environment:

      Linux / ant 1.7.0

      Description

      Originally described in ivy-user list : http://old.nabble.com/Transitive-resolving-issue---td27984462.html
      Here just a part of the discussion that explain the problem and the temporary work around :
      Consider the following use case :

      moduleA has one of its dependencies like this :
      <dependency org="log4j" name="log4j" rev="1.2.14" transitive="false"/>
      moduleB has one of its dependencies like this :
      <dependency org="log4j" name="log4j" rev="1.2.15" transitive="false"/>

      While moduleC use moduleA and moduleB I have something like this :
      <dependency org="moduleA.org" name="moduleA" rev="moduleA.rev"/>
      <dependency org="moduleB.org" name="moduleB" rev="moduleB.rev"/>

      This seems to be very banal BUT, when running the ivy:resolve task the
      log4j-1.2.15 evicts the log4j-1.2.14 which seems to be a good thing!
      but thereafter the resolve task does not consider the transitivity has false
      and try to resolve all the dependencies of log4j-1.2.15

      If I remove moduleA.org and use only moduleB.org then the resolve task
      behave correctly (I mean there is no resolution of transitives
      dependencies).
      The reverse case is also true.

      A work-around is available by resolving conflict explicitly with something like :
      <conflict org="moduleA.org" module="moduleA" rev="moduleA.rev"/>

      1. jira-ivy-1178.zip
        3 kB
        david herviou

        Activity

        Hide
        Maarten Coene added a comment -

        I couldn't reproduce your problem. Could you try again with current trunk version? Maybe it's already fixed by some other changes?

        Show
        Maarten Coene added a comment - I couldn't reproduce your problem. Could you try again with current trunk version? Maybe it's already fixed by some other changes?
        Hide
        david herviou added a comment -

        Try the example I gave but resolution is done.
        Seems that my real life use case is a little bit more complicated (use of configuration and configuration exclusion), try to investigated to spot the real "failure", if failure exist !

        Show
        david herviou added a comment - Try the example I gave but resolution is done. Seems that my real life use case is a little bit more complicated (use of configuration and configuration exclusion), try to investigated to spot the real "failure", if failure exist !
        Hide
        Maarten Coene added a comment -

        If you generate an ivy:report after your ivy:resolve you might see where these log4j dependencies are coming from...

        Show
        Maarten Coene added a comment - If you generate an ivy:report after your ivy:resolve you might see where these log4j dependencies are coming from...
        Hide
        david herviou added a comment -

        Finally found the real-life use case that turns my head upside-down !

        Attachment contains a simple project for identifying it. By default the conflitManager is on latest-revision. If you run ant retrieve, the task will failed because transitives dependencies are tried to be retrieved.

        Switch the conflictManager to 'all' and the problem disappeared. The previous workaround is still available.

        Show
        david herviou added a comment - Finally found the real-life use case that turns my head upside-down ! Attachment contains a simple project for identifying it. By default the conflitManager is on latest-revision. If you run ant retrieve, the task will failed because transitives dependencies are tried to be retrieved. Switch the conflictManager to 'all' and the problem disappeared. The previous workaround is still available.
        Hide
        Maarten Coene added a comment -

        I was able to reproduce the problem and located the bug in the code.
        I hope I'll be able to commit a fix tomorrow, stay tuned...

        Maybe another possible workaround might be to switch the order of your dependencies so that log4j-1.2.14 gets resolved first... (not really tested with your uploaded example though)

        Maarten

        Show
        Maarten Coene added a comment - I was able to reproduce the problem and located the bug in the code. I hope I'll be able to commit a fix tomorrow, stay tuned... Maybe another possible workaround might be to switch the order of your dependencies so that log4j-1.2.14 gets resolved first... (not really tested with your uploaded example though) Maarten
        Hide
        Maarten Coene added a comment -

        I've committed a fix in SVN trunk.
        Could you please give it a try to see if it also fixes your problem and post your feedback here?

        thanks!
        Maarten

        Show
        Maarten Coene added a comment - I've committed a fix in SVN trunk. Could you please give it a try to see if it also fixes your problem and post your feedback here? thanks! Maarten
        Hide
        david herviou added a comment -

        I've tried with svn trunk revision 929601 and checked on real use case : fix is OK!

        Show
        david herviou added a comment - I've tried with svn trunk revision 929601 and checked on real use case : fix is OK!
        Hide
        david herviou added a comment -

        Done with FIX commited in trunk

        Show
        david herviou added a comment - Done with FIX commited in trunk

          People

          • Assignee:
            Maarten Coene
            Reporter:
            david herviou
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development