ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Oster" <>
Subject RE: specify versions separate from dependencies
Date Wed, 27 Feb 2008 18:25:01 GMT
Point taken on the desire to not use the work around; I was just
suggesting it as an, albeit suboptimal, way to work with the support
that is there today.

On your second point about writing a tool to automatically specify the
versions, I'm not sure I really see the point of using a system like Ivy
if you want to "hard specify" every single version of all your
dependencies. If you don't do "all" of them, you are left with the same
potential need for automatic conflict resolution, as some new version of
a module may introduce a new conflict, which you don't have a hard
specified rule.

Therefore, I think what is needed is the ability to provide Ivy with
mediation/arbitration rules which are consulted at the time when
decisions are being made on which versions to use for transitive
dependencies.  Currently Ivy supports plugging in logic to the decision
only when there is a conflict; what is missing is just a way to plug in
logic when there aren't conflicts.  I think a new section in the Ivy
file which contains the current "conflicts" section, and a new
"versioncontraints" section would suffice.  I agree with other posts
"dependencyManagement" is a poor and confusing name for such a section,
but don't really have many better suggestions, but feel the name should
be derived from the fact that it's a place to provide rules to the
engine when processing transitive dependencies.  A "manager" syntax
similar to "conflicts" would probably suffice.  You could then implement
your own versioncontraints manager to read a "versions file" if you
liked; others could simply hard-code the versions they want for specific
transitive dependencies.


-----Original Message-----
From: Harald Braumann [] 
Sent: Wednesday, February 27, 2008 12:36 PM
Subject: Re: specify versions separate from dependencies

On Wed, 27 Feb 2008 11:50:11 -0500
"Scott Oster" <> wrote:

> Maybe I'm not seeing the whole picture, but I think this could be 
> supported in Ivy today (although maybe not as cleanly as you like).
> Could you not just make use of the conflict management system (as 
> previously suggested), by implementing a resolution scheme that took 
> the "nearest" version in the dependency graph.  That is, If A depends 
> on B and C and B depends on C, you take A's version of C even if it is

> older than Bs (as A's version of C is a shorter path through the 
> dependency graph than B's is).

No, believe me, it only leads to tears. We used nearest with maven for
our project. This project is quite big and contains a lot of
dependencies. The problem is now, that there are multiple roots, because
its a multi-module project. So nearest really depends on where you
start. In addition there is the uber-build, that takes all the modules
and creates the installation package. Now if you change a dependency
anywhere, it's completely unpredictable which indirect dependencies
change. And not only in one place, but in multiple places.
Even worse, until recently maven selected the dependency at random, if
there where conflicting dependencies at the same distance. They have
fixed this by ordering them alphabetically, so now, at least, its
deterministic. But this doesn't help you either, because whether your
software runs or not doesn't really depend on alphabetic ordering of
dependencies. Also using latest doesn't help, because again, that's no
criterion for whether your software runs or not. Thus I want to be able
to control the versions in a single place in some deterministic and,
more importantly, graspable way.

> The issue you mentioned before with this approach is that there is 
> potentially no conflict if you just want to specify a hard version of 
> transitive dependencies, even if there is no conflict.  I think the 
> way around this is you simple introduce a dependency on the module you

> want to override (thus introducing a conflict).  This is a bit of a 
> leaky abstraction, as your module doesn't directly need this module 
> (just through transitivity), but I don't see it as a huge issue as to 
> specify that you require a specific version of a module which you 
> don't directly depend on, implies to me that you have already leaked 
> that abstraction (i.e you already know you need it, and want to 
> control the version).

Adds more woe than relieve. Firstly, you have to do it in multiple
places (see above) and it is guaranteed that you will forget it
somewhere and have subtle inconsistencies. Secondly, every time you
change a dependency you have to walk through all your overrides and
check if they still apply.

>From the many, many hours of experience I have in fixing dependency
problems, I can tell you that for any reasonable complex project,
automatic conflict resolution does not work and leads to a lot of
problems and headache. Thus I want to be in control of the versions.
Once this is supported by ivy, my plan is to create a tool that creates
the versions file for you. It would resolve all the dependencies
recursively and write the versions file. It would also tell you all
conflict, which you have to resolve by hand (IMHO the only sensible
thing to do). If you change any dependency, you re-run the tool and it
tells you all the new conflicts (by comparing with the old version of
the versions file).


> That being said, I would support this being more straight-forwardly 
> controllable; it's something I looked for when I moved to Ivy.  In 
> terms of organization would suggest some new dependencyManagement 
> configuration section should be introduced with contains this 
> information, as well as the conflict management section as the two are

> related, and you would need to specify the semantics of which 
> overrides the other when your conflict management information is in 
> conflict with your specific version constraints. :)
> Scott

View raw message