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
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.
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.
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*
Cheers,
Antoine
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
