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 Mon, 19 Nov 2007 21:56:36 GMT
On Nov 19, 2007 9:47 PM, Jing Xue <jingxue@digizenstudio.com> wrote:

>
>
> Hi,
>
> I ran into a situation where some dependencies are triggered based on
> how another one is resolved.
>
> Spring 2.5 has reorganized some of the modules. So what was in 2.0's
> spring-hibernate3 will be in 2.5's spring-orm, and what was in 2.0's
> spring-dao will be in 2.5's spring-tx.  I have a library project that
> I'm hoping to support both 2.0 and 2.5 for a while, so I have this in
> the ivy.xml:
>
> <dependency org="org.springframework" name="spring-hibernate3"
> rev="[2.0, 2.6["  />
>
> which of course will always resolve to the latest 2.0.x because there
> is never going to be a 2.5 version for it.  The bigger problem is I
> can't find a sane way to specify the replacement, spring-orm, as a
> dependency so that the whole thing works with both spring 2.0 and 2.5.
>
> The condition involved here is probably more complex than a version
> switch. It would look something like "use spring-hibernates if
> spring-core is resolved to 2.0, but use spring-orm if spring-core is
> resolved to 2.5."
>
> Any thoughts?

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.

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

Xavier


>
> --
> Jing Xue
>
>
>


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