On Tue 2007-12-11 at 10:55h, Jing Xue wrote on ivy-user:
:
> I think you are right in principle - that a published ivy.xml does
> indeed carry assumptions from the original settings with which it was
> resolved. Although it's probably not the conflict manager - or
> anything involved in pinpointing the dependency revisions, because in
> a published ivy.xml, all the properties are substituted, all the
> transitive depdencies have fixed revisions.
They may have fixed revisions, but unless they are used together with
the strict conflict manager, these are not necessarily the revisions
resolved by a depending module. Repeating my example:
A ------> C1 -> D
A -> B -> C2 -> D
B -> C3 -> D
After publishing a version of B, B's published ivy.xml contains a
fixed version for D. Now we resolve the dependencies for some version
of A that depends on that version of B, but which happens to depend on
a different version of D than the depending version of B does. If
then, for example, the resolution process for A applies a different
latest-strategy when resolving the conflict between the D versions
than B has been using, the resulting version of D might actually be
older than the minimum required version transitively required by B
according to its own latest-strategy for D.
:
> As far as I can see, the parts that a published ivy.xml _doesn't_
> remember, yet have an impact on any future builds, are the
> repositories on it, for ivy still needs to go somewhere to actually
> fetch the dependencies and their ivy.xml's. And that's not going to
> be helped by versioning the repositories, unless all these versions of
> repositories are made available to the build at the same time, and ivy
> adds the repository version into the published ivy.xml.
That sounds right. Versioning the repositories can make the results
reproducible, but not necessarily correct. :)
-- Niklas Matthies
