On Mon, Mar 31, 2008 at 3:59 PM, Gilles Scokart <[EMAIL PROTECTED]> wrote:
> On 31/03/2008, Xavier Hanin <[EMAIL PROTECTED]> wrote: > > On Mon, Mar 31, 2008 at 2:27 PM, Gilles Scokart <[EMAIL PROTECTED]> > wrote: > > > > > On 31/03/2008, Niklas Matthies <[EMAIL PROTECTED]> wrote: > > > > On Mon 2008-03-31 at 08:39h, Johannes Stamminger wrote on ivy-user: > > > > > > > > > On Saturday 29 March 2008, Gilles Scokart wrote: > > > > > > On 28/03/2008, Johannes Stamminger < > > > [EMAIL PROTECTED]> wrote: > > > > > > > > : > > > > > > > the exclude and override I could imagine that it would make > > > sense to > > > > > > > specify them per dependency - not only globally for all > > > dependencies ... > > > > > > > ? > > > > > > > > > > > > Why would you exclude or overwrite it for one dependency but > not > > > for the > > > > > > others? > > > > > > > > : > > > > > P1 -> L1 -> L2 > > > > > and > > > > > P1 -> L3 -> L2 > > > > > > > > > > With the global exclude L2 still is not in P1 though it is > needed > > > > > now. With specifying it only for the dependency to L1, people in > P1 > > > > > get triggered to analyse the dependency again (when detecting > the > > > > > newly included L2). With specifying it globally one runs into > > > > > problems in worst case (dynamic load of L2 in L1) only very > late. > > > > > > > > > > > > I wonder how the semantics is intended to be anyway (by Ivy). > > > > What if L1 excludes (some revisions of) L2 because it isn't > compatible > > > > with them? Can L3 cause such in incompatible revision to be > included > > > > anyway? What if L3 uses <override>? > > > > > > > > In that light, it seems to me that applying exclude/override > globally > > > > is the only thing that makes sense. The logic by which Ivy prunes > > > > dependency subtrees is based on the assumption that it doesn't > matter > > > > in which order conflicts are considered; that the result will be > the > > > > same regardless of the order. Exclude/override/conflict do break > that > > > > assumption, unless they are applied globally. > > > > > > > > > > > > -- Niklas Matthies > > > > > > > > > > Ugh. You see it more globally than me. > > > I was just thinking it is only usefull at a global level, meaning > > > accros all the dependency of a module. > > > You pinpoint (rightfully I think) that it only make sense even more > > > globaly, accross all the modules that may depends on you. > > > It looks like we will need to manage the conflicts between > > > exclusion/overwrite/conflict managment ?? > > > > > > I don't think it's a problem. The implementation currently works like > this: > > override is used to override a dependency descriptor, so that Ivy > behave > > *exactly* as if the dependency has been declared with the overriding > value. > > exclude works by excluding the dependency from the tree, exactly as if > the > > dependency was not declared. As such it beats override. > > conflict is used only when there is a conflict, after exclude/override > which > > are used at metadata level, while conflict management is used at > resolution > > level > > > > It's still your responsibility when you write a module descriptor to > perform > > the required exclude/override/conflict management to make sure you get > a set > > of compatible dependencies. > > > > This seems fine to me. Do you foresee any problem? > > > > Xavier > > > > > > Well, the use case presented by Niklas is not covered : What if I want > to exclude a transitive dependency because I'm incompatible with it? > Maybe I want to tell to my users "hey, never run my code with this > depdendency!". > > Is this scenario realist? I don't know? I think you can't give that much power to a module. If the caller really want to use the module with another "incompatible" one, it's up to him. Maybe he will just load it in a separate classloader, you never know. I think current system with new mechanism already offers a good deal of flexibility and control, and we'll later see if we need new mechanisms. But I think this goes beyond the scope of this discussion and the target for 2.0.0. Xavier > > > -- > Gilles Scokart > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
