ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jing Xue <>
Subject Re: conditional resolving
Date Tue, 20 Nov 2007 14:57:15 GMT

Quoting Xavier Hanin <>:

> On Nov 20, 2007 2:04 AM, Jing Xue <> 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".

> 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.  I wouldn't  
mind working on it.  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-)


> Xavier

View raw message