Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: pass (athena.apache.org: domain of xavier.hanin@gmail.com
 designates 209.85.198.190 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=ZIW3mgNt+BcfGVt6BY8wPYh6bc3ufHo2RAICwkO7p1AB3mU6dFPrvyysOgctRIJ7SkDcZxuHy2gaVgNQbqWgnsNKsxXlhdfFccojzvOIgLReSU1Dhts/9HReQGMQe3LD0JNAaWRPi5RHO1Y6m9HsmzlLNb3DPm/CiW12UkWVTBg=
Message-ID: <635a05060802271002h75b24c39kddde5d8dae6c2d19@mail.gmail.com>
Date: Wed, 27 Feb 2008 19:02:57 +0100
From: "Xavier Hanin" <xavier.hanin@gmail.com>
To: ivy-user@ant.apache.org
Subject: Re: specify versions separate from dependencies
In-Reply-To: <20080227183538.1ae0a0c6@sbs173>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_13571_24253147.1204135378049"
References: <635a05060802270617i57bf3697t80968959e8349e1b@mail.gmail.com>
	 <24048DC1F8522C44B83040006BCC8FC370A572@troy.bmi.ohio-state.edu>
	 <20080227183538.1ae0a0c6@sbs173>

------=_Part_13571_24253147.1204135378049
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Wed, Feb 27, 2008 at 6:35 PM, Harald Braumann <harry@unheit.net> wrote:

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

Interesting idea. Note that if you need overriding only when you have
conflicts, the conflicts/manager elements in Ivy files can already fit your
needs AFAIU: you run a resolve with a conflict manager which only collects
conflicts from your tool, then ask the user to select versions, and create
the conflict management section to include in your main ivy file. Since
inclusion is not (yet?) supported, you still need to do some kind of
automatic merging before giving this to Ivy, but this is not the hardest
part. The end result would be really close to what you would have with a
dependency override mechanism, except that conflicts would still appear as
conflicts in dependency reports. WDYT?

Xavier


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


-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

------=_Part_13571_24253147.1204135378049--