ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hekmat, Payam" <>
Subject RE: Dependency order issue with transitive dependencies
Date Thu, 08 Jul 2010 22:25:36 GMT
The mailing list seems to have rejected my log, but that's ok. In
digging through the code, I think I've found a couple of possible
sources of the issue. 

>From what I can tell:
1) The resolution process starts by resolving:
   A -> 1.1
   B -> 2.1 (requires A 1.0)
2) Seeing the conflict between A v1.0 required by B v2.1 and A v1.1
(which it chose originally), it evicts A 1.1 and restarts the resolution
3) It resolves:
   A -> 1.0
   B -> 2.1
4) In 3, it calls ResolveData.replaceNode for A v1.+, replacing it with
the VisitData for A v1.0 (so the map has "A;1.+" and "A;1.0" pointing to
the same VisitData object)
5) It resolves C -> v3.1 and loads its dependencies
6) In 5, it calls ResolveData.register, which sets the VisitData.node =
A v1.1 (required by C v3.1). This is the same structure as in (4)
7) It tries to resolve conflicts for A v1.1 using
ResolveEngine.resolveConflicts which calls ResolveEngine.resolveConflict
for each parent in the graph. 
8) In ResolveEngine.resolveConflict, when it reaches the root, it uses "
node.getRootModuleConf());" to get the resolved nodes. However, this
uses "node.getRealNode()" internally, which uses the VisitData structure
from (4) and (6) and ends up returning A v1.1 rather than what was
actually resolved by the root, A v1.0.
"ancestor.getNode().getResolvedRevisions" returns the correct revision.

I figure the problem is either in steps (4), (5), or (8), but I'm not
familiar enough with the Ivy codebase to know if I'm on the right track
or if the VisitData object is a red herring and the problem is somewhere
else. I'd appreciate any insights. 

	Payam Hekmat

-----Original Message-----
From: Hekmat, Payam [] 
Sent: Thursday, July 08, 2010 11:02 AM
Subject: RE: Dependency order issue with transitive dependencies

I tried last night from a trunk source build and this morning with 2.2.0
rc1 with no change. The original attempt was on 2.1.0. I quickly tested
on 2.0.0-beta1 and the issue is there as well, so it's not likely a

I've attached an ant run with debug logging enabled just in case it's of
any help. 

	Payam Hekmat

-----Original Message-----
From: Maarten Coene [] 
Sent: Thursday, July 08, 2010 7:03 AM
Subject: Re: Dependency order issue with transitive dependencies

Could you please try again with Ivy 2.2.0 RC1 which has just been
It contains some bugfixes that might be related to your problem.


----- Original Message ----
From: "Hekmat, Payam" <>
Sent: Thu, July 8, 2010 12:27:45 AM
Subject: Dependency order issue with transitive dependencies

I have 3 modules in the following configuration ('->' indicates a
Module A: v1.0
Module B: v2.0
            ->A v1.0
            ->A v1.0
Module C: v3.0
            ->A v1.0
            ->B v2.1 
            ->A v1.1
            ->B v2.1 (yes, C v3.1 is technically impossible to resolve)

With an ivy file declaring the dependencies: 
        <dependency org="foo" name="A" rev="1.+" />
        <dependency org="foo" name="B"  rev="2.+" />
        <dependency org="foo" name="C"  rev="3.+" />

Using the 'latest-compatible' conflict manager, I'd expect it to resolve
to A v1.0, B v2.0, C v3.0, but it only resolves to B v2.1, C v3.1. If I
change the order of the dependency elements around (e.g. A,C,B or
B,C,A), it resolves correctly. In the original order, it restarts the
resolve process trying to handle incompatibilities between A v1.0 and A

Any insights on where the issue could be? While this is a trivial
example, it's not feasible for me to order the dependencies in practice.

Thanks in advance,
    Payam Hekmat


View raw message