ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Gill" <llign...@gmail.com>
Subject Re: Sharing ivyconf.xml
Date Tue, 11 Dec 2007 00:06:38 GMT
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 <ml_ivy-user@nmhq.net> 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

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