Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Date: Tue, 8 Apr 2003 17:35:15 +0200 (CEST)
From: Stephan Michels <stephan@apache.org>
To: cocoon-dev@xml.apache.org
Subject: Re: [GUMP] Build Failure - cocoon-block-fop
In-Reply-To: <b6uoud$ej4$1@main.gmane.org>
Message-ID: <Pine.LNX.4.44.0304081723520.5773-100000@vern.chem.tu-berlin.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Tue, 8 Apr 2003, Stefano Mazzocchi wrote:

> on 4/8/03 5:08 PM Stephan Michels wrote:
>
> > On Tue, 8 Apr 2003, Nicola Ken Barozzi wrote:
> >>
> >>Stefano Mazzocchi wrote, On 08/04/2003 16.04:
> >>...
> >>
> >>>So adding tests makes perfect sense, while adding documentation or dist
> >>>targets does not: if our documentation fails, the code dependency of
> >>>others projects will remain valid, so we should not impede others from
> >>>being able to build on us.
> >>
> >>Usually there can be three methods of doing this.
> >>
> >>1 - One, which works with projects that are in alpha state, makes junit
> >>tests not fail, ie failonerror="false", so that a report can be
> >>generated and browsed. Same with distros.
> >>
> >>2 - Another is to make a cocoon-test project, and have that depend on
> >>cocoon and unit test it. Thus the unit test can pass and cocoon give the
> >>jar. This is quite common for Gump, as you see from the project definitions.
> >>
> >>3 - Finally there is super-strict mode, where a project doesn't want to
> >>give it's jar if not all tests pass. Not usually recomended.
> >>
> >>I'd go with 1 for unit tests, and eventually use regexps to nag on test
> >>failures if we need them later on.
> >>
> >>For functional tests like the anteater ones, case 2 is the best.
> >
> >
> > I'm for 3 ;-) That's reason why it called XP, and it forces you to
> > keep the testcases uptodate.
>
> Wait. You should keep an eye on what gump tries to do.
>
> If you fail because you didn't pass the tests, the projects that depend
> on you will not be run, meaning that another day will pass before they
> know if something wrong happened to them.
>
> I'd go for 2 since it's the balance between nagging in case something
> bad happens (this is what XP is about!) and not stopping others to be
> able to get nagged.

A complete project only for the tests? :-|

And for 1) the problem is that a successful gump build doesn't throw a
email into cocoon-dev.

I'm biased ... I think 3) is the right solution, because it kicks more
asses to do something (fast), including me.

Stephan.