ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Matthies <ml_ivy-u...@nmhq.net>
Subject Re: Ivy confs masquerading as dependencies' revisions
Date Fri, 26 Jun 2009 21:01:31 GMT
Chiming in...

On Fri 2009-06-26 at 12:42h, Garima Bathla wrote on ivy-user:
:
> And let's follow your suggestion and put the dependency on JUnit directly in
> Foo's ivy.xml:
>     <dependency org="org.junit" name="junit" rev="3.8.2" conf="..."
> />
> 
> Now, the question arises, what to do about Bar's dependency on JUnit?
> Suppose I keep it there:
>     <dependency org="org.junit" name="junit" rev="[3.8.2,4.6]" conf="..." />
> 
> Having this dependency there in Bar actually causes Ivy to ignore Foo's
> request for JUnit 3.8.2. Instead, JUnit 4.6 is what gets resolved.

The way that this normally works is that either JUnit 4.x is supposed
to be backwards compatible with JUnit 3.x (which I believe is the
case), then there's no problem with getting the former when depending
on the latter, or else if there is no compatiblity, then these should
not be the same module, but rather two different modules junit3 and
junit4. Which then of course may clash with each other when they are
both retrieved, but that is a different problem. The only other way
I'm aware of to robustly handle this is to write a custom Conflict
Manager that fails upon conflicts between JUnit 3.x and JUnit 4.x.

The other question is what Bar is actually depending on. Having the
same artifact depend on either JUnit 3 or on JUnit 4 at the same time
is a bit strange. Does Bar check at runtime which of both is present
and behaves differently then? Or does it just depend on JUnit 3, which
actually means that it depends on anything that is compatible with
JUnit 3, which is a condition that might be fulfilled by JUnit 4?

-- Niklas Matthies

Mime
View raw message