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
