Stefano Mazzocchi wrote:
Dear gumpmaisters,Hi Stefano,
excalibur-logging is breaking basically 40% of our tree and nobody gives a damn.
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
Antoine,
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 pieces.
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*
True.
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.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
