ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Kilian <>
Subject Re: Resolving Dependencies not to patch level
Date Wed, 19 Sep 2007 15:11:59 GMT
On Wed, Sep 19, 2007 at 10:42:57AM -0400, Jing Xue wrote:
> >Yes, but if you don't put your SCM repository in SCM it's difficult to
				  ^^^ I guess that should read "Ivy"
> >ensure build reproducibility. You need to be absolutely sure you won't 
> >ever
> >modify any module in your repository. Ever. And I've seen too many times
> >people modifying a third party module metadata because there were a
> >dependency missing. IMO dependency management tools like Ivy are useful to
> >determine the set of dependencies a module need, by using transitive
> >dependencies resolution and conflict management. But they do not preclude
> >the use of a SCM for module repository management.
> True.  Perhaps a good compromise would be to maintain separate repos  
> for ivy files and the module artifacts (i.e. using dual resolvers),  
> and keep the ivy repo under version control.

Here's what we do, currently using *one* large Ivy repository
containing ivy files and artefacts for both third party modules and
our own software:

- Third party modules are under CVS control, but only the ivy files, not
  the artefacts or checksums; for those we have appropriate .cvsignore

- Our own software in the Ivy repository is *not* under CVS control at
  all. Instead, we commit the delivered ivy files right into the
  *source* CVS module as described on my mini survey.

The reason for this: if something's wrong with our own ivy files,
that can be fixed by fixing the ivy file and make a new release.
If there's some active branch for hotfixes, then this branch's ivy
file can be fixed, too. This is feasible for us because we've usually
only two "important" revisions of a module: the one under development
and the one currently used in a production environment. So it's
enough to keep the delivered ivy files committed (and tagged) in
the sources of your software.

On the other hand, for third party modules, we can't make a new
just because the ivy file needs a fix. But sometimes you *have* to
fix such ivy files, so we have our own third-party/only-ivy-files
module in our CVS. Just to have history and, should it break a
former reproducible build take actions to repair it.

Thinking of it, I think I'll also start to create *and publish* a
full resolution report whenever making a release. This could help
to detect unintended changes when reproducing a historic build.

> Jars don't get changed  so often or shouldn't at all, and I for
> one am always dreaded by keeping large binary files in SCM. 8-)

Yes, I don't like big binaries in SCM, too. And for sure, if you've,
say, different xerces-2.6.0.jars at different points in time, you're
in serious trouble ;-)


View raw message