On 6/12/07, Gilles Scokart <[EMAIL PROTECTED]> wrote:
The current ivy implementation can use version ranges in its dependency. When using a range ivy search for the latest revision available in the repository that will match the range. (Correct me if I'm wrong!).
Indeed, this is how Ivy works. Shouldn't ivy take into account the other dependencies as well? For
example, if we have A depending on C version [1.0,3.0[, and A depending B which depends on V version 1.5. The current implementation will return the latest available revision contained in [1.0,3.0[. Shouldn't ivy return the revision 1.5, even if there are 2.1 in the repository? (If it is already possible to do that, tell me how).
It's something that could be useful, and that we "need" to implement to be compatible with maven 2 version ranges processing. This requires some thought, because this is something that is even more useful in published metadata. Some users have already requested something like storing two information in the published metadata: the compatible range and the exact version to which the dependency resolution lead at time of publication (the only information available right now). This could be useful for conflict management too, to tell if a dependency is resolved outside the compatiblity scope (which is also something that maven 2 does). Also, I'm wondering if it wouldn't make sense to take the first available
version. Indeed if I say that my modules requires 1.+, I think it's better to compile with a 1.0 version. Indeed, the probability is bigger that a version compiled/tested with 1.0 works also with a 1.1 than the opposite (a version compiled/tested with 1.1 working with a 1.0). Also when we publish, if we want to fix the published dependencies, I'm wondering if it wouldn't not be better to publish 1.0, instead of 1.x (where x is the highest number available when we make the build).
Maybe this is something that need to be more flexible than it is. Version mediation is not an easy thing, but we could try to have something flexible enough to handle both cases (take the latest or oldest possible which is not conflicting with another one). What makes this kind of thing difficult is that we do not have access to the whole dependency graph: we need to download metadata to acquire information about modules, and this is a costly operation that Ivy tries to do as few times as possible. But improving this kind of flexibility would definitely be helpful if well thought. Xavier WDYT?
Gilles
-- Xavier Hanin - Independent Java Consultant Manage your dependencies with Ivy! http://incubator.apache.org/ivy/
