Quoting Niklas Matthies <[EMAIL PROTECTED]>:
On Tue 2007-12-11 at 09:06h, John Gill wrote on ivy-user:
That's why we are dependent on a particular version of the
ivyconf.xml. That way the choice of conflict manager can't change
when you try and reproduce the build.
True, it can't change for a particular build, but it could change
between the build and a build of a depending module. Example:
A ------> C1 -> D
A -> B -> C2 -> D
B -> C3 -> D
If builds of A uses a different retrieval or conflict resolution
policy for D than builds of B, then B could break (or misbehave in
subtle ways). Having B depend on a particular ivyconf.xml doesn't
translate to A, which could apply a whole different D than B assumes.
More generally, a published ivy.xml still assumes particular settings
from an ivyconf.xml.
These settings must in general be the same
between building some module B and later having its published ivy.xml
being used for building some other module A. So one might want to have
module A have a dependency on the correct Ivy settings for this, but
that (I think) breaks down once the settings change between versions
of module B, several of which might (transitively or intransitively)
be relevant in the resolution/retrieval process for building a version
of module A.
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. A later session of
ivy:resolve can simply take this file and produce the transitive
dependencies _without_ going through the same resolution process again.
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.
Namespaces might be something else that when changed could have an
impact. Anything else?
--
Jing Xue
