gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: feature request: top critical failures
Date Sun, 07 Mar 2004 23:32:28 GMT
Antoine Lévy-Lambert wrote:

> Stefano Mazzocchi wrote:
>> Dear gumpmaisters,
>>  excalibur-logging is breaking basically 40% of our tree and nobody 
>> gives a damn.
> Hi Stefano,
> Actually in the last one or two months, I have been "giving a damn" as 
> you said. With the participation of the corresponding communities,
> and the help of Stefan Bodewig, we got a number of builds with a lot of 
> dependencies, located upstream of excalibur-logging, repaired :
> - jaxen,
> - dom4j,
> - xml-fop,
> - .velocity


I seriously apologize if my comment sounded offensive. With "nobody 
gives a damn" I meant none of the avalon people. Which is really making 
me sad and a little bit worried, given how much cocoon relies on those 

> But you are right, if the number of dependencies is displayed, it will 
> be easier to detect the spots which are harming a lot gump.

I think gumpy suffers from "data overload" syndrome: too many numbers, 
too much eye candy... it's harder to spot where the errors are.

> Concerning excalibur-logging :
> The build file of excalibur-logging does not match the source tree of 
> this component, and expects java sources to be at a place where they are 
> not.
> I will try to suggest a new build.xml to the avalon team for this 
> component. May be it could be built with Maven, but I do not know Maven, 
> and
> I do not know either the interface between gump and Maven.
> I am also wondering whether we should not define some gump best 
> practices for ant build files of individual projects :
> - the full path of each dependency jar should be a property, not just 
> the name of the jar (so that gump can override the property properly)
> - preferably, the build.xml of each project should not attempt to build 
> another project, or there should be a way for gump (by setting properties)
> to prevent this from happening.
> I am thinking here about xdoclet. xdoclet is expecting xjavadoc to be in 
> a parallel source tree ( ../xjavadoc ) which is OK for gump
> and tries to build the xjavadoc.jar (not good) when the xdoclet build 
> file thinks the xjavadoc.jar is not uptodate with the sources.

There are two paths here:

  1) make gump smart enough to work with that's out there
  2) lobby to change things for them to adapt in whatever gump way

Technically, 2 is king.

Socially, 2 is impossible.

> I will give a shout to the xdoclet guys concerning this later. The point 
> I am trying to make is that :
> *A good build file (for gump) is a simple build file*


Unfortunately, this is real life and real life is a bitch.

We must build gump so that it can cope with the real world, the opposite 
is just too hard to be true.


View raw message