You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stephan Michels <st...@apache.org> on 2003/04/10 11:09:48 UTC

Re: [GUMP] Build Failure


On Wed, 9 Apr 2003, Stephan Michels wrote:

>
>
> On Tue, 8 Apr 2003, Sam Ruby wrote:
>
> > Stefano Mazzocchi wrote:
> > >>>
> > >>>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'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.
> >
> > Go for 3.
> >
> > A <depend> element in a gump project descriptor does *not* mean that the
> > build was successful.  It merely means that all the jars declared in the
> > descriptor are present after the build was run.
> >
> > So... you can structure the ant targets so that you produce the jars,
> > then run the tests.  If the jars are produced and the tests fail, then
> > you will get nagged and projects which depend on you will get built.
>
> Okay, I have now included the test targets. Hopefully don't break
> this thing :) We will see...

Seems to be broken. *f..k* The dependency to the scratchpad went into the
gump-core target, and I don't know why :-/

http://gump.cocoondev.org/cocoon.html

I tried vizant as Nicola suggested, but GraphViz doesn't compile. grmpf#!

I'll take a look into it....

Stephan.