> -----Original Message-----
> From: Niklas Matthies [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 05, 2007 8:56 AM
> To: [email protected]
> Subject: Re: Sharing ivyconf.xml
>
> On Wed 2007-12-05 at 08:19h, Xavier wrote on ivy-user:
> > Sharing settings through a shared filesystem or url is fine, but I
> > suggest versionning your settings
>
> We'll certainly put them into CVS.
>
> > for the sake of build reproducibility.
>
> But this part is confusing me. If for example we change something like
> our repository structure (or location), then the attempting to build
> an old version of a module using the corresponding old ivyconf.xml
> won't succeed.
>
> Our thinking was that by definition ivyconf.xml is outside of module
> versioning and needs to be version-independent, since it is used to
> resolve and retrieve *any* versions of the modules, not just the
> "current" ones. Hence I wrote:
>
> > > It seems (luckily) that there's no need to have versioning of the
> > > ivyconf.xml, in the sense that different versions of a project
> would
> > > require different versions of ivyconf.xml (which would introduce
> > > dependency issues on ivyconf.xml...).
>
> You appear to be saying that different versions of a project could
> indeed require different (historic) versions of ivyconf.xml. I'm
> wondering what kind of changes to ivyconf.xml you're thinking of.

A change of default conflict manager, default latest strategy, triggers, ... Or 
a change of syntax or the use of new features following an upgrade to a new Ivy 
version: 3.0, or 4.0, I don't know, I'm speaking about reproducibility over a 
very long period of time, and your whole build system should be versioned 
(including the tools you use like Ant and Ivy, the JDK, and maybe even the OS).

Xavier

>
> -- Niklas Matthies

Reply via email to