gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "BAZLEY, Sebastian" <>
Subject RE: Gump build failures
Date Mon, 24 Nov 2003 13:22:36 GMT
> -----Original Message-----
> From: Stefan Bodewig []
> Sent: 24 November 2003 07:52
> To:
> Subject: Re: Gump build failures
> On Fri, 21 Nov 2003, Sebastian BAZLEY
> <> wrote:
> > However, like (some?/many?) other projects, JMeter has its own
> > copies of the external jar files in CVS in its lib directory. [This
> > was set up before I got involved.]
> This goes absolutely against the very idea of Gump, but ...
> If your really, really, really want to use your own jars, you can
> point Gump to them by using <work> elements.
> Just be nice and turn them into plain dependencies once your upstream
> projects are buildable again, please.  You will also benefit from
> doing so as you will know about backwards incompatible changes in the
> projects you depend on a lot earlier.

OK, understood.


The problem I'm having is is not so much that the builds do not seem to be
working well at present (though that did prompt me to investigate) - it is
more that there seem to be two conflicting requirements here:
- building all projects from ground up
- building a particular project using known dependencies

The latter build should make it easier to investigate errors (fewer
changes), as well as reflecting more closely what is likely to be released
(in the case of JMeter at least!).

I don't know if there is a solution to this, short of performing the build
twice - e.g. if the build works when performed against fixed dependencies,
then redo the build against the latest dependencies.

Individual committers can perform their own project builds/tests, but it is
unlikely that they will have a full range of platforms to build on, and then
there is the issue of publishing the build results.


View raw message