ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harald Braumann <ha...@unheit.net>
Subject Re: specify versions separate from dependencies
Date Wed, 27 Feb 2008 17:35:38 GMT
On Wed, 27 Feb 2008 11:50:11 -0500
"Scott Oster" <oster@bmi.osu.edu> 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).

harry

> 
> 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
> 

Mime
View raw message