ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: conditional resolving
Date Tue, 20 Nov 2007 06:49:54 GMT
On Nov 20, 2007 2:04 AM, Jing Xue <> wrote:

> On Mon, Nov 19, 2007 at 10:56:36PM +0100, Xavier Hanin wrote:
> >
> > This use case is very interesting, and a tricky one. I don't see any way
> to
> > express this cleanly and concisely with current Ivy version. You could
> use a
> > custom resolver to handle this very specific logic, but I'm not the sure
> the
> > idea is satisfying.
> 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. 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

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

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

> So the custom resolver may be asked to make the decision
> before the relevant data is available.
> > Another possible solution is to use two configurations in you module,
> one
> > for spring 2 and one for spring 2.5. Since I don't recommend declaring a
> > dependency on the same module twice with different revisions in the same
> > module (it happens to mostly work, but is not actually supported and
> subject
> > to some bugs), what could be done is define two virtual modules (no
> > publications), one for spring 2, and another for spring 2.5, both having
> > different names. Then you make your module depend on one of them in one
> conf
> > and on the other in the other conf. But then you loose the advantage of
> > conflict resolution for this virtual module at least.
> Hmm... I hadn't thought of virtual modules. But as you pointed out, this
> can get complicated, because not only my module depends on these spring
> modules, so do some of the 3rd party tools we use.

So virtual modules is not a solution.


> > All of this depends
> > also on who you would like to take the decision of which version of
> spring
> > to use. Is it a direct client of your module (in which case the
> > configurations solution may be interesting) or a transitive client?
> It's most likely a direct client that will make the decision.
> Cheers.
> --
> Jing Xue
> >
> > Xavier

Xavier Hanin - Independent Java Consultant

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