ant-ivy-user mailing list archives

We don't use dynamic dependencies either, on the grounds that it isn't
deterministic.
We do version our ivysettings.xml, and the in-house tool that we use that
keeps all the information in a database I was on about tells us which
version to use (well actually, it tells the ant build file what version to
use).
Ah.... Now I see what you mean... If A was build with ivy settings 1.1 and 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.
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.
On Dec 10, 2007 10:48 PM, Niklas Matthies <ml_ivy-user@nmhq.net> wrote:
> On Mon 2007-12-10 at 21:47h, John Gill wrote on ivy-user:
> :
> > Basically absolutely everything must be under source control, and
> labeled
> > and released with a script to the repository.
>
> I agree (in theory ;)). But that's not really my point. My point is
> that you can't (practically, reliably) have Ivy dependencies from
> module revisions onto shared Ivy settings. Because the purpose, or
> at least one major purpose, of the Ivy settings is to define the
> resolution process across available revisions (in particular in the
> light of dynamic dependencies and non-strict conflict resolution).
>
> For example, how do you resolve a conflict between revision 1.5 and
> revision 2.0 of a module if the latter requires different Ivy settings
> for resolution than the former? The question doesn't even make sense.
>
> Changing Ivy settings is out of scope at that level of versioning.
> When changing Ivy settings in incompatible ways (i.e. resolution
> processes involving earlier module revisions don't work as intended
> any more), you need a meta level of versioning, such as the one you
> describe with rebuilding repositories from source control. But it
> doesn't make much sense to version the basic Ivy settings within the
> very repository they are defining policies upon, as this would
> confound the meta level with the Ivy level of versioning.
>
> -- Niklas Matthies
>
--
Regards,
John Gill