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 Mon, 10 Dec 2007 12:47:39 GMT
Well that depends. Where I work we have a tool that keeps all the
dependencies in a database (which is backed up obviously), then as we always
label what we build (including labeling the ivy.xml, build.xml, etc) and
keep this information in our dependency manager database. Then we can build
the whole repository from scratch using just a few boot strapping components
by checking out each component from the labels and build it from the bottom
up.

So we need to know:
What version of java and ant we used to build it.
The ivyconf.xml
Where the source code is (and the label to the version we are building).

The important part is that all our 3rd party libraries are under source
control as well (we use clearcase although I'd prefer subversion), and the
3rd party libraries are released using ant/ivy as well. In other words,
regardless of the type of artifact, and where it originally came from, if it
is in our repository, then it must also be under source control and be
labeled. We never rely on external repositories for anything other than
getting the original artifact. Frankly, I think that anyone who relies on
external maven repos, etc is just asking for trouble. Case in point, when
ivy moved from jayasoft to apache, I thought it was touch and go getting a
few things like ivyDE because the jayasoft web site was down for a while.
Now imaging that we had ported our whole system to ivy, and then all of a
sudden, we couldn't down load it anymore, and we didn't have our own copy
under source control and it didn't go to apache. That would have been a
disaster for us and ivy.

Basically absolutely everything must be under source control, and labeled
and released with a script to the repository. The simply reason for this is
that we take the few that any one of these external dependencies could
disappear from the internet as any time, and even if there is a newer/better
version of it, why should we be forced to upgrade because we were too lazy
to version control and manage it properly.

I guess my view is on build reproducibility is very black and white. It is
either reproduceable or it isn't.

I'll shut up now.

On Dec 10, 2007 8:18 PM, Niklas Matthies <ml_ivy-user@nmhq.net> wrote:

> On Wed 2007-12-05 at 12:48h, Xavier Hanin wrote on ivy-user:
> > > -----Original Message-----
> > > From: Niklas Matthies [mailto:ml_ivy-user@nmhq.net]
> > > Sent: Wednesday, December 05, 2007 8:56 AM
> :
> > > 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).
>
> Ok, I was (or meant to be) talking about versioning in the context of
> Ivy module versioning. In the context of build reproducability at the
> level you're talking about, you'd in particular have to version the
> whole module repository itself to make sure to get reproducable
> resolution results.
>
> -- Niklas Matthies
>



-- 
Regards,
John Gill

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