ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Archie Cobbs <archie.co...@gmail.com>
Subject Re: Ivy confs masquerading as dependencies' revisions
Date Sat, 27 Jun 2009 02:18:16 GMT
D'oh! I stand corrected... sorry for the misinformation.

-Archie

On Fri, Jun 26, 2009 at 4:16 PM, Niklas Matthies <ml_ivy-user@nmhq.net>wrote:

> 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 <garima.bathla@gmail.com
> >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
> on http://ant.apache.org/ivy/history/trunk/settings/latest-strategies.html
> ).
>
> 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
>



-- 
Archie L. Cobbs

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