ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Matthies <>
Subject Re: Ivy confs masquerading as dependencies' revisions
Date Fri, 26 Jun 2009 21:16:42 GMT
On Fri 2009-06-26 at 15:42h, Archie Cobbs wrote on ivy-user:
> On Fri, Jun 26, 2009 at 2:42 PM, Garima Bathla <>wrote:
> > 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.
> OK, you can stop right there...  that's clearly broken and I think
> must be a bug.

No, it's by design. Rev="3.8.2" actually means "anything compatible
with version 3.8.2". The default conflict manager, "latest-revision"
assumes that any newer revision is compatible (unlike the "strict"
conflict manager, which assumes that revisions are only compatible
with themselves). Furthermore, as its name implies, it resolves
conflicts by selecting the "latest" revision from the two conflicting
sets of revisions. Which revision is the latest is determined by the
current "latest strategy", which by default is "latest-revision" (same
name as the conflict manager) which selects the revision with the
greater revision number (according to the algorithm (under-)specified

You might want to try the "latest-compatible" conflict manager instead
(its notion of "compatible" is different from how I used the word in
the above), which I believe would select revision 3.8.2 in the
scenario above.

-- Niklas Matthies

View raw message