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: conditional resolving
Date Tue, 20 Nov 2007 15:24:44 GMT
On Nov 20, 2007 3:57 PM, Jing Xue <jingxue@digizenstudio.com> wrote:

>
> Quoting Xavier Hanin <xavier.hanin@gmail.com>:
>
> > On Nov 20, 2007 2:04 AM, Jing Xue <jingxue@digizenstudio.com> wrote:
> >
> >> This could be interesting. I suppose since a resolver has access to the
> >> current
> >> resolution map, it could at least theoretically make a "stateful"
> >> decision. One potential caveat though is that, IIUC, when two modules
> >> aren't depending on one another, the order of them being resolved is
> >> undefined.
> >
> > It isn't really undefined, the order is always the same, and depends on
> the
> > order of the dependencies defined in your metadata.
>
> True.  On the other hand though, I suspect (by skimming through the
> parsing and resolving code and I _could_ be very wrong) that this
> behavior is like this only because of the way it's implemented. The
> behavior itself is always deterministic, and a rather sane one at
> that, but I don't recall seeing it documented anywhere, which is what
> I meant by "undefined".

I understand, but at least in my mind it's not only the result of the
deterministic implementation, it's really how I think the resolution should
happen. I sometime recommend to put a dependency on the actual revision you
want to finally get at the beginning of the dependencies section, to make
sure eviction of other revisions will happen before actually downloading the
module. So IMO this is more something that should be documented than
undefined :-)

>
>
> > It's very similar to a
> > preorder tree traversal, except that we walk through a graph and that we
> try
> > to avoid visiting evicted nodes. But it's true that it isn't under
> control
> > of the resolver, it's under control of people writing metadata. So it
> may be
> > a problem for you, depending on how well you can control the way
> metadata is
> > written.
> >
> > Resolving the problem without imposing some kind of order is pretty
> > challenging. Maybe this could be done with some modifications in the
> > ResolveEngine, to let a door open just before the end of the resolution
> > process, to let you resolve this dependency only when the rest of the
> graph
> > has been resolved. But the least I can says is that this is not an easy
> > solution.
>
> You mean some sort of "post resolving" extension point which is
> exposed by the resolve engine to handle any dependencies left
> unresolved by the standard algorithm?  That'd be cool.

Yes something like that.


>  I wouldn't
> mind working on it.

That'd be cool :-)


>  It'd probably be way out of scope at the moment,
> though. 8-)

:-)


>
>
> >
> > Another solution I see if you are sure the module making the decision is
> the
> > direct client of your module, is to define a custom parser based on the
> > XmlModuleDescriptorParser we provide, but which "sort" the dependency
> > descriptors returned to make sure your module is always at the end. Then
> in
> > a custom resolver you can make the stateful decision based on the full
> graph
> > of dependencies available at this time. This is not the cleanest thing
> I've
> > ever imagined, but it may work :-)
>
> I think for now we are going to take the easy route - which is to make
> a code branch for spring 2.0 support. Seeing Spring 2.5 just got
> released (only after two RCs, that was quick!) last night, and it's
> supposed to be a drop-in replacement, we might luck out with a rather
> short transition period.
>
> Thanks for the advices. It was a rather interesting discussion even
> from a theoretical standpoint. 8-)

My pleasure.

Xavier

>
>
> Cheers.
> --
> Jing
>
> >
> > Xavier
>
>
>


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