Ivy
  1. Ivy
  2. IVY-1233

Infinite loop in latest-compatible conflict manager

    Details

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

      Description

      Attempting to resolve org="com.gargoylesoftware" name="htmlunit" rev="2.7" from the Ivy RoundUp repository with the latest-compatible conflict manager configured leads to an infinite loop:

      $ ant
      Buildfile: build.xml
      
      clean:
      
      bug:
      [ivy:resolve] :: Ivy 2.2.0-rc1 - 20100629224905 :: http://ant.apache.org/ivy/ ::
      [ivy:resolve] :: loading settings :: file = /Users/archie/IVYBUG/settings.xml
      [ivy:resolve] BLACKLISTING [org.apache.xerces#xerces;2.7+ blacklisted to evict org.apache.xerces#xerces;2.7+ in favor of org.apache.xerces#xerces;2.9.1 in com.gargoylesoftware#htmlunit;2.7 for default]
      [ivy:resolve] BLACKLISTING [org.apache.xerces#xerces;2.7+ blacklisted to evict org.apache.xerces#xerces;2.7+ in favor of org.apache.xerces#xerces;2.9.1 in com.gargoylesoftware#htmlunit;2.7 for default]
      [ivy:resolve] BLACKLISTING [org.apache.xerces#xerces;2.7+ blacklisted to evict org.apache.xerces#xerces;2.7+ in favor of org.apache.xerces#xerces;2.9.1 in com.gargoylesoftware#htmlunit;2.7 for default]
      [ivy:resolve] BLACKLISTING [org.apache.xerces#xerces;2.7+ blacklisted to evict org.apache.xerces#xerces;2.7+ in favor of org.apache.xerces#xerces;2.9.1 in com.gargoylesoftware#htmlunit;2.7 for default]
      [ivy:resolve] BLACKLISTING [org.apache.xerces#xerces;2.7+ blacklisted to evict org.apache.xerces#xerces;2.7+ in favor of org.apache.xerces#xerces;2.9.1 in com.gargoylesoftware#htmlunit;2.7 for default]
      [ivy:resolve] BLACKLISTING [org.apache.xerces#xerces;2.7+ blacklisted to evict org.apache.xerces#xerces;2.7+ in favor of org.apache.xerces#xerces;2.9.1 in com.gargoylesoftware#htmlunit;2.7 for default]
      [ivy:resolve] BLACKLISTING [org.apache.xerces#xerces;2.7+ blacklisted to evict org.apache.xerces#xerces;2.7+ in favor of org.apache.xerces#xerces;2.9.1 in com.gargoylesoftware#htmlunit;2.7 for default]
      ...
      

      See attached test case. To run it, unpack ZIP file, cd into IVYBUG, copy ant-2.2.0-rc1.jar in the current directory and then run "ant".

      1. ivybug.zip
        1 kB
        Archie Cobbs
      2. ivy-1233.patch
        5 kB
        Payam Hekmat
      3. ivy-1233-test.patch
        7 kB
        Payam Hekmat

        Issue Links

          Activity

          Hide
          Maarten Coene added a comment -

          Seems a duplicate of IVY-1204, which contains a potential patch for the issue.

          Show
          Maarten Coene added a comment - Seems a duplicate of IVY-1204 , which contains a potential patch for the issue.
          Hide
          Nell Gawor added a comment -

          I built Ivy from trunk with the patch from IVY-1204 applied, copied the jar into the test directory and ran the test. The behavior did not change – I still see an infinite loop. This seems to be either a different issue from 1204, or the patch does not work as it is supposed to.

          Show
          Nell Gawor added a comment - I built Ivy from trunk with the patch from IVY-1204 applied, copied the jar into the test directory and ran the test. The behavior did not change – I still see an infinite loop. This seems to be either a different issue from 1204, or the patch does not work as it is supposed to.
          Hide
          Payam Hekmat added a comment -

          Can you try the attached patch (test patch included)? From what I could tell, the issue was in LatestCompatibleConflictManager when one of the conflicts was a pattern.

          Show
          Payam Hekmat added a comment - Can you try the attached patch (test patch included)? From what I could tell, the issue was in LatestCompatibleConflictManager when one of the conflicts was a pattern.
          Hide
          Nell Gawor added a comment -

          Is this patch against trunk? The revision numbers don't seem to match.

          Show
          Nell Gawor added a comment - Is this patch against trunk? The revision numbers don't seem to match.
          Hide
          Payam Hekmat added a comment - - edited

          It's against trunk, but it looks like mine was out of sync. There were no changes to LatestCompatibleConflictManager since that rev, so the changes should apply cleanly to the latest in SVN. The test patch is easy enough to apply manually since the only conflict seems to be on the method added to ResolveTest, but I'll sync and test again tonight just to be safe.

          edit: Just tested against the latest in trunk and all seems fine; no previously passing tests are failing.

          Show
          Payam Hekmat added a comment - - edited It's against trunk, but it looks like mine was out of sync. There were no changes to LatestCompatibleConflictManager since that rev, so the changes should apply cleanly to the latest in SVN. The test patch is easy enough to apply manually since the only conflict seems to be on the method added to ResolveTest, but I'll sync and test again tonight just to be safe. edit: Just tested against the latest in trunk and all seems fine; no previously passing tests are failing.
          Hide
          Archie Cobbs added a comment -

          I can't apply the patch:

          [archie@Archie-Cobbss-MacBook-Pro.local] $ patch -p0 < ivy-1233.patch      
          (Stripping trailing CRs from patch.)
          patching file src/java/org/apache/ivy/plugins/conflict/LatestCompatibleConflictManager.java
          Hunk #1 FAILED at 188.
          Hunk #2 FAILED at 215.
          Hunk #3 FAILED at 262.
          Hunk #4 FAILED at 274.
          4 out of 4 hunks FAILED -- saving rejects to file src/java/org/apache/ivy/plugins/conflict/LatestCompatibleConflictManager.java.rej
          

          I'm trying to apply it to this revision:

          [archie@Archie-Cobbss-MacBook-Pro.local] $ svn info
          Path: .
          URL: https://svn.apache.org/repos/asf/ant/ivy/core/trunk
          Repository Root: https://svn.apache.org/repos/asf
          Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
          Revision: 1030980
          Node Kind: directory
          Schedule: normal
          Last Changed Author: hibou
          Last Changed Rev: 1030584
          Last Changed Date: 2010-11-03 13:12:20 -0500 (Wed, 03 Nov 2010)      
          
          Show
          Archie Cobbs added a comment - I can't apply the patch: [archie@Archie-Cobbss-MacBook-Pro.local] $ patch -p0 < ivy-1233.patch (Stripping trailing CRs from patch.) patching file src/java/org/apache/ivy/plugins/conflict/LatestCompatibleConflictManager.java Hunk #1 FAILED at 188. Hunk #2 FAILED at 215. Hunk #3 FAILED at 262. Hunk #4 FAILED at 274. 4 out of 4 hunks FAILED -- saving rejects to file src/java/org/apache/ivy/plugins/conflict/LatestCompatibleConflictManager.java.rej I'm trying to apply it to this revision: [archie@Archie-Cobbss-MacBook-Pro.local] $ svn info Path: . URL: https://svn.apache.org/repos/asf/ant/ivy/core/trunk Repository Root: https://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 1030980 Node Kind: directory Schedule: normal Last Changed Author: hibou Last Changed Rev: 1030584 Last Changed Date: 2010-11-03 13:12:20 -0500 (Wed, 03 Nov 2010)
          Hide
          Payam Hekmat added a comment -

          Not sure what to tell you...it worked fine on the checkout I made last night:

          \workspace\ivy>patch -p0 < ivy-1233.patch
          (Stripping trailing CRs from patch.)
          patching file src/java/org/apache/ivy/plugins/conflict/LatestCompatibleConflictManager.java
          
          \workspace\ivy>svn info
          Path: .
          URL: https://svn.apache.org/repos/asf/ant/ivy/core/trunk
          Repository Root: https://svn.apache.org/repos/asf
          Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
          Revision: 1030793
          Node Kind: directory
          Schedule: normal
          Last Changed Author: hibou
          Last Changed Rev: 1030584
          Last Changed Date: 2010-11-03 13:12:20 -0500 (Wed, 03 Nov 2010)
          
          Show
          Payam Hekmat added a comment - Not sure what to tell you...it worked fine on the checkout I made last night: \workspace\ivy>patch -p0 < ivy-1233.patch (Stripping trailing CRs from patch.) patching file src/java/org/apache/ivy/plugins/conflict/LatestCompatibleConflictManager.java \workspace\ivy>svn info Path: . URL: https://svn.apache.org/repos/asf/ant/ivy/core/trunk Repository Root: https://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 1030793 Node Kind: directory Schedule: normal Last Changed Author: hibou Last Changed Rev: 1030584 Last Changed Date: 2010-11-03 13:12:20 -0500 (Wed, 03 Nov 2010)
          Hide
          Archie Cobbs added a comment -

          OK, I had to manually strip the CR's from the file to get the patch to work.. must be a problem with the Mac OS version of the patch(1) command...

          Now the infinite loop is gone and I get this instead, which is presumably expected:

          BUILD FAILED
          /Users/archie/IVYBUG/build.xml:16: impossible to resolve dependencies:
          	org.apache.xerces#xerces;2.7+ (needed by []) conflicts with org.apache.xerces#xerces;2.9.1 (needed by [com.gargoylesoftware#htmlunit;2.7])
          

          Thanks!

          Show
          Archie Cobbs added a comment - OK, I had to manually strip the CR's from the file to get the patch to work.. must be a problem with the Mac OS version of the patch(1) command... Now the infinite loop is gone and I get this instead, which is presumably expected: BUILD FAILED /Users/archie/IVYBUG/build.xml:16: impossible to resolve dependencies: org.apache.xerces#xerces;2.7+ (needed by []) conflicts with org.apache.xerces#xerces;2.9.1 (needed by [com.gargoylesoftware#htmlunit;2.7]) Thanks!
          Hide
          Sven Zethelius added a comment -

          Ran into this one with 2.2.0. In a multi-layer deep dependency tree on log4j with a conflict, using compatible-cm and latest-revision. Even using force="true" on the log4j dependency of com.expedia.e3.es.order.adaptor.loyalty-test still enters the infinite loop.

          [ivy:resolve] BLACKLISTING [expedia#log4j;[1.2.16,1.3[ blacklisted to evict expedia#log4j;[1.2.16,1.3[ in favor of expedia#log4j;1.2.9 in expedia#com.expedia.e3.es.order.adaptor.loyalty-test;working@BELSVENZ06WD for default]
          [ivy:resolve] BLACKLISTING [expedia#log4j;[1.2.16,1.3[ blacklisted to evict expedia#log4j;[1.2.16,1.3[ in favor of expedia#log4j;1.2.9 in expedia#com.expedia.e3.es.order.adaptor.loyalty-test;working@BELSVENZ06WD for default]
          [ivy:resolve] BLACKLISTING [expedia#log4j;[1.2.16,1.3[ blacklisted to evict expedia#log4j;[1.2.16,1.3[ in favor of expedia#log4j;1.2.9 in expedia#com.expedia.e3.es.order.adaptor.loyalty-test;working@BELSVENZ06WD for default]
          [ivy:resolve] BLACKLISTING [expedia#log4j;[1.2.16,1.3[ blacklisted to evict expedia#log4j;[1.2.16,1.3[ in favor of expedia#log4j;1.2.9 in expedia#com.expedia.e3.es.order.adaptor.loyalty-test;working@BELSVENZ06WD for default]
          ... repeat until process killed.
          
          Show
          Sven Zethelius added a comment - Ran into this one with 2.2.0. In a multi-layer deep dependency tree on log4j with a conflict, using compatible-cm and latest-revision. Even using force="true" on the log4j dependency of com.expedia.e3.es.order.adaptor.loyalty-test still enters the infinite loop. [ivy:resolve] BLACKLISTING [expedia#log4j;[1.2.16,1.3[ blacklisted to evict expedia#log4j;[1.2.16,1.3[ in favor of expedia#log4j;1.2.9 in expedia#com.expedia.e3.es.order.adaptor.loyalty-test;working@BELSVENZ06WD for default ] [ivy:resolve] BLACKLISTING [expedia#log4j;[1.2.16,1.3[ blacklisted to evict expedia#log4j;[1.2.16,1.3[ in favor of expedia#log4j;1.2.9 in expedia#com.expedia.e3.es.order.adaptor.loyalty-test;working@BELSVENZ06WD for default ] [ivy:resolve] BLACKLISTING [expedia#log4j;[1.2.16,1.3[ blacklisted to evict expedia#log4j;[1.2.16,1.3[ in favor of expedia#log4j;1.2.9 in expedia#com.expedia.e3.es.order.adaptor.loyalty-test;working@BELSVENZ06WD for default ] [ivy:resolve] BLACKLISTING [expedia#log4j;[1.2.16,1.3[ blacklisted to evict expedia#log4j;[1.2.16,1.3[ in favor of expedia#log4j;1.2.9 in expedia#com.expedia.e3.es.order.adaptor.loyalty-test;working@BELSVENZ06WD for default ] ... repeat until process killed.
          Hide
          Maarten Coene added a comment -

          I've applied the patch to SVN trunk which should fix this problem with latest-compatible conflictmanager when using dynamic revisions.

          Thanks for the contribution!

          Show
          Maarten Coene added a comment - I've applied the patch to SVN trunk which should fix this problem with latest-compatible conflictmanager when using dynamic revisions. Thanks for the contribution!
          Hide
          Sven Zethelius added a comment -

          This is not fixed in trunk. 2.2.1.alpha_20120313100444 still repros the problem. I managed to get the infinite loop with the following set of dependencies:
          A (being built) Depends on B pVer.main.+, C [1.0,2.0[, D [1.5,1.7[
          B pVer.main.0.0 Depends on D [1.6.1,2.0[
          B 1.0.0 Depends on D [1.6.1,2.0[
          B 1.1.0 Depends on D [1.6.1,2.0[
          C 1.0.0 Depends on B [1.0,2.0[, D [1.6.0,1.7[
          C 1.1.0 Depends on B [1.1,2.0[, D [1.6.0,1.7[
          D no Dependencies

          C and A share no overlapping version for B. This should fail the resolve. Instead it results in an infinite loop.

          [ivy:resolve] found expedia#B;1.1.0 in ReleasedBuilds
          [ivy:resolve] [1.1.0] expedia#B;[1.0,2.0[
          [ivy:resolve] found osgi#D;1.6.1 in ThirdPartyOrg
          [ivy:resolve] [1.6.1] osgi#D;[1.6.1,2.0[
          [ivy:resolve] found expedia#C;pCC.main.2.0 in DirectedBuilds
          [ivy:resolve] [pCC.main.2.0] expedia#C;pCC.main.+
          [ivy:resolve] BLACKLISTING [expedia#B;1.1.0 blacklisted to evict expedia#B;1.1.0 in favor of expedia#B;pCC.main.+ in expedia#A;working@BELSVENZ07-W7 for default]
          [ivy:resolve] found expedia#B;1.0.0 in ReleasedBuilds
          [ivy:resolve] [1.0.0] expedia#B;[1.0,2.0[
          [ivy:resolve] BLACKLISTING [expedia#B;1.0.0 blacklisted to evict expedia#B;1.0.0 in favor of expedia#B;pCC.main.+ in expedia#A;working@BELSVENZ07-W7 for default]
          [ivy:resolve] found expedia#B;1.2.0.0 in DirectedBuilds
          [ivy:resolve] [1.2.0.0] expedia#B;[1.0,2.0[
          [ivy:resolve] BLACKLISTING [expedia#B;1.2.0.0 blacklisted to evict expedia#B;1.2.0.0 in favor of expedia#B;pCC.main.+ in expedia#A;working@BELSVENZ07-W7 for default]
          [ivy:resolve] found expedia#B;pCC.main.1.9 in DirectedBuilds
          [ivy:resolve] [pCC.main.1.9] expedia#B;pCC.main.+
          [ivy:resolve] BLACKLISTING [expedia#B;[1.0,2.0[ blacklisted to evict expedia#B;[1.0,2.0[ in favor of expedia#B;pCC.main.1.9 in expedia#A;working@BELSVENZ07-W7 for default]
          [ivy:resolve] BLACKLISTING [expedia#B;[1.0,2.0[ blacklisted to evict expedia#B;[1.0,2.0[ in favor of expedia#B;pCC.main.1.9 in expedia#A;working@BELSVENZ07-W7 for default]
          [ivy:resolve] BLACKLISTING [expedia#B;[1.0,2.0[ blacklisted to evict expedia#B;[1.0,2.0[ in favor of expedia#B;pCC.main.1.9 in expedia#A;working@BELSVENZ07-W7 for default]
          [ivy:resolve] BLACKLISTING [expedia#B;[1.0,2.0[ blacklisted to evict expedia#B;[1.0,2.0[ in favor of expedia#B;pCC.main.1.9 in expedia#A;working@BELSVENZ07-W7 for default]
          [ivy:resolve] BLACKLISTING [expedia#B;[1.0,2.0[ blacklisted to evict expedia#B;[1.0,2.0[ in favor of expedia#B;pCC.main.1.9 in expedia#A;working@BELSVENZ07-W7 for default]
          [ivy:resolve] BLACKLISTING [expedia#B;[1.0,2.0[ blacklisted to evict expedia#B;[1.0,2.0[ in favor of expedia#B;pCC.main.1.9 in expedia#A;working@BELSVENZ07-W7 for default]

          Show
          Sven Zethelius added a comment - This is not fixed in trunk. 2.2.1.alpha_20120313100444 still repros the problem. I managed to get the infinite loop with the following set of dependencies: A (being built) Depends on B pVer.main.+, C [1.0,2.0[, D [1.5,1.7[ B pVer.main.0.0 Depends on D [1.6.1,2.0[ B 1.0.0 Depends on D [1.6.1,2.0[ B 1.1.0 Depends on D [1.6.1,2.0[ C 1.0.0 Depends on B [1.0,2.0[, D [1.6.0,1.7[ C 1.1.0 Depends on B [1.1,2.0[, D [1.6.0,1.7[ D no Dependencies C and A share no overlapping version for B. This should fail the resolve. Instead it results in an infinite loop. [ivy:resolve] found expedia#B;1.1.0 in ReleasedBuilds [ivy:resolve] [1.1.0] expedia#B;[1.0,2.0[ [ivy:resolve] found osgi#D;1.6.1 in ThirdPartyOrg [ivy:resolve] [1.6.1] osgi#D;[1.6.1,2.0[ [ivy:resolve] found expedia#C;pCC.main.2.0 in DirectedBuilds [ivy:resolve] [pCC.main.2.0] expedia#C;pCC.main.+ [ivy:resolve] BLACKLISTING [expedia#B;1.1.0 blacklisted to evict expedia#B;1.1.0 in favor of expedia#B;pCC.main.+ in expedia#A;working@BELSVENZ07-W7 for default] [ivy:resolve] found expedia#B;1.0.0 in ReleasedBuilds [ivy:resolve] [1.0.0] expedia#B;[1.0,2.0[ [ivy:resolve] BLACKLISTING [expedia#B;1.0.0 blacklisted to evict expedia#B;1.0.0 in favor of expedia#B;pCC.main.+ in expedia#A;working@BELSVENZ07-W7 for default] [ivy:resolve] found expedia#B;1.2.0.0 in DirectedBuilds [ivy:resolve] [1.2.0.0] expedia#B;[1.0,2.0[ [ivy:resolve] BLACKLISTING [expedia#B;1.2.0.0 blacklisted to evict expedia#B;1.2.0.0 in favor of expedia#B;pCC.main.+ in expedia#A;working@BELSVENZ07-W7 for default] [ivy:resolve] found expedia#B;pCC.main.1.9 in DirectedBuilds [ivy:resolve] [pCC.main.1.9] expedia#B;pCC.main.+ [ivy:resolve] BLACKLISTING [expedia#B;[1.0,2.0[ blacklisted to evict expedia#B;[1.0,2.0[ in favor of expedia#B;pCC.main.1.9 in expedia#A;working@BELSVENZ07-W7 for default] [ivy:resolve] BLACKLISTING [expedia#B;[1.0,2.0[ blacklisted to evict expedia#B;[1.0,2.0[ in favor of expedia#B;pCC.main.1.9 in expedia#A;working@BELSVENZ07-W7 for default] [ivy:resolve] BLACKLISTING [expedia#B;[1.0,2.0[ blacklisted to evict expedia#B;[1.0,2.0[ in favor of expedia#B;pCC.main.1.9 in expedia#A;working@BELSVENZ07-W7 for default] [ivy:resolve] BLACKLISTING [expedia#B;[1.0,2.0[ blacklisted to evict expedia#B;[1.0,2.0[ in favor of expedia#B;pCC.main.1.9 in expedia#A;working@BELSVENZ07-W7 for default] [ivy:resolve] BLACKLISTING [expedia#B;[1.0,2.0[ blacklisted to evict expedia#B;[1.0,2.0[ in favor of expedia#B;pCC.main.1.9 in expedia#A;working@BELSVENZ07-W7 for default] [ivy:resolve] BLACKLISTING [expedia#B;[1.0,2.0[ blacklisted to evict expedia#B;[1.0,2.0[ in favor of expedia#B;pCC.main.1.9 in expedia#A;working@BELSVENZ07-W7 for default]
          Hide
          Sven Zethelius added a comment -

          If it helps, the loop is stuck repeating:
          while (iter.hasNext()) {
          IvyNode other = (IvyNode) iter.next();
          if (!versionMatcher.accept(other.getResolvedId(), mrid)) {
          // incompatibility found
          if (!handleIncompatibleConflict(parent, conflicts, node, other))

          { // <-- throw exception here causes the INF loop... return null; }

          }
          }

          It keeps repeating the conflicts: expedia#B;pCC.main.1.9, expedia#B;[1.0,2.0[

          Show
          Sven Zethelius added a comment - If it helps, the loop is stuck repeating: while (iter.hasNext()) { IvyNode other = (IvyNode) iter.next(); if (!versionMatcher.accept(other.getResolvedId(), mrid)) { // incompatibility found if (!handleIncompatibleConflict(parent, conflicts, node, other)) { // <-- throw exception here causes the INF loop... return null; } } } It keeps repeating the conflicts: expedia#B;pCC.main.1.9, expedia#B;[1.0,2.0[
          Hide
          Sven Zethelius added a comment -

          The infinite loop from my repro above stems from LatestCompatibleConflictManager.blackListIncompatibleCaller. It is looking at the callers of the current node. When node is the root node, the caller list is empty. This results in blacklisted.isEmpty()==true, but since dynamicCaller==true, it returns empty list instead of null. Then in the LatestCompatibleConflictManager.handleIncompatibleCaller, it does an addAll of an empty list (aka NO-OP).

          Digging back through the change log, IVY-663 relates. Before that and the previous patch change, blackListIncompatibleCaller would return null whenever blacklisted.isEmpty()==true.

          Here's a test case for the problem:
          public void testDynamicRootConflict() throws Exception {
          try {
          fixture
          .addMD("#A;conflict->

          {#B;[1.2,2.0[ #C;pCC.main.+ #D;[1.5,1.7[ }

          ")
          .addMD("#B;1.0.0->#D;[1.6.1,2.0[")
          .addMD("#B;1.1.0->#D;[1.6.1,2.0[")
          .addMD("#B;pCC.main.0.0->#D;[1.6.1,2.0[")
          .addMD("#C;1.0.0->

          {#B;[1.0,2.0[ #D;[1.6.0,1.7[ }

          ")
          .addMD("#C;1.1.0->

          {#B;[1.1,2.0[ #D;[1.6.0,1.7[ }

          ")
          .addMD("#C;pCC.main.1.9->

          {#B;pCC.main.+ #D;[1.6.0,1.7[ }

          ")
          .addMD("#D;1.6.1").init();
          fixture.resolve("#A;conflict");

          fail("Resolve should have failed with a conflict");
          } catch (StrictConflictException e)

          { // this is expected }

          }

          Show
          Sven Zethelius added a comment - The infinite loop from my repro above stems from LatestCompatibleConflictManager.blackListIncompatibleCaller. It is looking at the callers of the current node. When node is the root node, the caller list is empty. This results in blacklisted.isEmpty()==true, but since dynamicCaller==true, it returns empty list instead of null. Then in the LatestCompatibleConflictManager.handleIncompatibleCaller, it does an addAll of an empty list (aka NO-OP). Digging back through the change log, IVY-663 relates. Before that and the previous patch change, blackListIncompatibleCaller would return null whenever blacklisted.isEmpty()==true. Here's a test case for the problem: public void testDynamicRootConflict() throws Exception { try { fixture .addMD("#A;conflict-> {#B;[1.2,2.0[ #C;pCC.main.+ #D;[1.5,1.7[ } ") .addMD("#B;1.0.0->#D;[1.6.1,2.0[") .addMD("#B;1.1.0->#D;[1.6.1,2.0[") .addMD("#B;pCC.main.0.0->#D;[1.6.1,2.0[") .addMD("#C;1.0.0-> {#B;[1.0,2.0[ #D;[1.6.0,1.7[ } ") .addMD("#C;1.1.0-> {#B;[1.1,2.0[ #D;[1.6.0,1.7[ } ") .addMD("#C;pCC.main.1.9-> {#B;pCC.main.+ #D;[1.6.0,1.7[ } ") .addMD("#D;1.6.1").init(); fixture.resolve("#A;conflict"); fail("Resolve should have failed with a conflict"); } catch (StrictConflictException e) { // this is expected } }
          Hide
          Maarten Coene added a comment -

          ok, I've modified the LatestCompatibleConflictManager, and now it passes the original testcase attached to this issue and your new test case.
          Could you give latest trunk version a try to see if this issue is solved?

          Show
          Maarten Coene added a comment - ok, I've modified the LatestCompatibleConflictManager, and now it passes the original testcase attached to this issue and your new test case. Could you give latest trunk version a try to see if this issue is solved?
          Hide
          Sven Zethelius added a comment -

          It's working properly now in 2.2.1.alpha_20120324002314. Thanks for the quick turn around.

          Show
          Sven Zethelius added a comment - It's working properly now in 2.2.1.alpha_20120324002314. Thanks for the quick turn around.

            People

            • Assignee:
              Maarten Coene
              Reporter:
              Archie Cobbs
            • Votes:
              2 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development