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.
On Dec 11, 2007 12:34 AM, Niklas Matthies <[EMAIL PROTECTED]> wrote: > On Mon 2007-12-10 at 22:58h, John Gill wrote on ivy-user: > > We don't use dynamic dependencies either, on the grounds that it isn't > > deterministic. > > Even without dynamic dependencies, things like the choice of conflict > manager can influence the resolution result for diamond dependencies. > > : > > Ah.... Now I see what you mean... If A was build with ivy settings 1.1and B > > was built with ivy setting 2.3... and B depends on A. It actually > doesn't > > matter as each is built in their own right and the resolution will be > > deterministic, because the ivysettings.xml tells you what it does. > > Hmm... When you build B, where does the version of module A come from > in the repository you build B against? > And is that the version of A you distribute/package with B, or is it > an independently built version of A? > > : > > I think the thing to remember is that the tool we use provides a higher > > level meta data that is then injected into the ivy.xml files. If you are > > really interested in exactly how we do it, I'll blog it. > > Thanks, but currently we don't plan to go for that level of build > reproducability. What's important for us is to be able to relate > builds to source control versions (by building & publishing from > tagged sources), and to have stable (= reproducible) dependency > resolution during test & bugfix cycles. > > -- Niklas Matthies > -- Regards, John Gill
