ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maarten Coene <maarten_co...@yahoo.com>
Subject Re: Ivy-Resolver
Date Wed, 14 Mar 2012 09:51:41 GMT
Could you try again with latest ivy trunk?
It contains several fixes for the latest-compatible conflictmanager.

Maarten



________________________________
 From: Maurer Philipp <philipp.maurer@rheinmetall-ad.com>
To: "ivy-user@ant.apache.org" <ivy-user@ant.apache.org> 
Sent: Wednesday, March 14, 2012 10:22 AM
Subject: Ivy-Resolver
 
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.maurer@rheinmetall-ad.com<mailto:philipp.maurer@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.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message