Mailing-List: contact ivy-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of Xavier.Hanin@sas.com
 designates 149.173.6.152 as permitted sender)
From: Xavier Hanin <Xavier.Hanin@sas.com>
To: "ivy-user@incubator.apache.org" <ivy-user@incubator.apache.org>
Date: Wed, 5 Dec 2007 12:48:05 -0500
Subject: RE: Sharing ivyconf.xml
Thread-Topic: Sharing ivyconf.xml
Thread-Index: Acg3Rp9k54x5wQKSRDihdp7v8udz0wAH8E4Q
Message-ID: <345520A34347BA49B798F70B218ACD13043697F5E3@MERCMBX14.na.sas.com>
References: <20071205135552.GA91121@nmhq.net>
In-Reply-To: <20071205135552.GA91121@nmhq.net>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

> -----Original Message-----
> From: Niklas Matthies [mailto:ml_ivy-user@nmhq.net]
> Sent: Wednesday, December 05, 2007 8:56 AM
> To: ivy-user@incubator.apache.org
> 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 reproducib=
ility over a very long period of time, and your whole build system should b=
e versioned (including the tools you use like Ant and Ivy, the JDK, and may=
be even the OS).

Xavier

>
> -- Niklas Matthies