ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maurer Philipp <philipp.mau...@rheinmetall-ad.com>
Subject AW: Ivy-Resolver
Date Fri, 16 Mar 2012 06:47:35 GMT
Thanks for your answer. Do you also think that this is a bug ?

I already (happily) found out, that another problem I had with the latest-compatible resolver
had been solved on the trunk.
Unfortunately, this problem is reproducible with Apache Ivy 2.2.x-local-20120223003230 - 20120223003230
- This version is about 3 weeks old. 

Do you think it's worth trying a newer version of Ivy ?

Thanks,
Philipp


-----Ursprüngliche Nachricht-----
Von: Maarten Coene [mailto:maarten_coene@yahoo.com] 
Gesendet: Mittwoch, 14. März 2012 10:52
An: ivy-user@ant.apache.org
Betreff: Re: Ivy-Resolver

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
View raw message