ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jing Xue <jing...@digizenstudio.com>
Subject Re: Sharing ivyconf.xml
Date Tue, 11 Dec 2007 15:55:51 GMT

Quoting Niklas Matthies <ml_ivy-user@nmhq.net>:

> 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


Mime
View raw message