Hi all,

I discovered the following, big problem in Apache Ivy's "latest-compatible" 
resolver. My questions are: bug or feature ? Does anybody know any workarounds ?

Setup:
Modules:

1)      Master Module A

2)      Module B in 1.0

3)      Module C in 2.0 and 2.5

4)      Module D in 2.0 and 3.0

Dependencies (=> means "depends on"):

1)      Master-Module A => Module B in 1.0

2)      Master-Module A => Module D in 2.0

3)      Master-Module A does not depend directly on Module C

4)      Module B 1.0 => Module C in [2.0,...

5)      Module C 2.0 => Module D 2.0

6)      Module C 2.5 => Module D 3.0

What happens ?
I get a strange resolve error.

Why does this happen ?
The resolver resolves: Master-Module A => Module B 1.0 => Module C in [2.0,..] 
= (here is the problem !) Module C 2.5 => Module D 3.0 (which violates 
Master-Module A => Module D 2.0)
It looks like the resolver takes Module C in the highest revision available 
(which is 2.5) causing a conflict with the master module's dependencies, it 
does not correctly try to find "a compatible set", although there is one 
possible.

What is expected ?
I would expect A, B 1.0, C 2.0 and D 2.0 (which is a compatible, valid set)

Workarounds / Problems:
I realized that adding a direct dependency from Master-Module A to Module C 2.0 
solves the problem and leading to the compatible set A, B 1.0, C 2.0 and D 2.0. 
But this is extremely bad: I thought it was one of the central ideas of Ivy 
that the master module does not need to know indirect dependencies. Given the 
situation above I'm afraid that the master module needs to fix *all* 
dependencies including the indirect ones breaking the concept. More than that, 
one could break the build process easily just be adding a new version of some 
module messing up the resolve process:
Imagine, Module C in 2.5 is not created yet. Given that situation, everything 
works fine for all developers in master module A. Now someone just releases 
third party module C 2.5 totally independently for *another* project. *BANG* 
master module A does not resolve properly any longer.

Any ideas ?

Thanks,
Philipp

----------
Philipp Maurer
Software Engineer
Software Development Department

Rheinmetall Air Defence AG
Birchstrasse 155
PO Box
8050 Zurich
Switzerland

Phone: +41 44 316 25 56
Telefax: +41 44 316 30 34
philipp.mau...@rheinmetall-ad.com<mailto:philipp.mau...@rheinmetall-ad.com>
www.rheinmetall-defence.com<http://www.rheinmetall-defence.com/>

This message contains privileged and confidential information. If you are not 
the intended recipient, please notify us immediately and delete it.

Reply via email to