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 Thu, 06 Dec 2007 01:00:45 GMT
Xavier is right! Software Configuration Management isn't just about
versioning the software you are building, but also the software you use to
build your software, and how that software is configured. If you need to
setup environment variables, local properties files, copy some files locally
in order to set up a machine in a particular way before you can get your
build working, then you basically have a "magic machine" which is an anit
pattern.

You can read about this anti pattern here:
http://www.ibm.com/developerworks/java/library/j-ap10106/index.html
http://www.nofluffjuststuff.com/blog/paul_duvall/2006/07/the_magic_machine_antipattern.html

On Dec 6, 2007 2:48 AM, Xavier Hanin <Xavier.Hanin@sas.com> wrote:

> > -----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
> 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
>



-- 
Regards,
John Gill

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