ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: [LIKELY_SPAM]Re: specify versions separate from dependencies
Date Mon, 31 Mar 2008 12:55:28 GMT
On Mon, Mar 31, 2008 at 2:27 PM, Gilles Scokart <gscokart@gmail.com> wrote:

> On 31/03/2008, Niklas Matthies <ml_ivy-user@nmhq.net> 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 <
> Johannes.Stamminger@astrium.eads.net> 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


>
>
>
>
>
> --
> Gilles Scokart
>



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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message