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 14:56:17 GMT
On Mon, Mar 31, 2008 at 3:59 PM, Gilles Scokart <gscokart@gmail.com> wrote:

> On 31/03/2008, Xavier Hanin <xavier.hanin@gmail.com> wrote:
> > 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
> >
> >
>
> 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/

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