Re: BATCH: All dressed up, with nowhere to go...
this is a very cool feature. I just love all the intelligence that gump is developing lately! -- cheers, - Leo Simons --- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles Opinions -- http://articles.leosimons.com/ --- We started off trying to set up a small anarchist community, but people wouldn't obey the rules. -- Alan Bennett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: feature request: top critical failures
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 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]
Re: feature request: top critical failures
Actually in the last one or two months, I have been giving a damn as you said. I suspect Stefano meant more from the owners, not all the Gumpmeisters 'cos we are a caring bunch. ;-) We've noticed all you've achieved ... (hmm, we need a FOG Factor for a count of projects dependencies that folks have returned to the fold. ;-) 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. The way is it (was) meant to work is on types maven ant (I think this is the goal, to get a build.xml) and maven gump to get a Gump descriptor. These then get check in, and the rest you know. I beleive Stefan knows of a reason why some mkdir entries often need to get things to work, but that can be step two. BTW: We do now have Gump (at least Gumpy) building via Maven, and I'd like to see it tried on something real. This occurs when maven is used instead of ant in the descriptor. http://lsd.student.utwente.nl/gump/jakarta-gump-test/gump-test-maven1.html http://lsd.student.utwente.nl/gump/jakarta-gump-test/gump-test-maven2.html Unfortunately if one sets a dependency on maven -- not actually necessary right now, one doesn't get a build: http://lsd.student.utwente.nl/gump/incubator-geronimo/incubator-geronimo.html http://lsd.student.utwente.nl/gump/incubator-geronimo/incubator-geronimo_details.html#Definition I am also wondering whether we should not define some gump best practices for ant build files of individual projects : Not a bad idea, we could add it to this (intended to be Gump best practices). http://gump.apache.org/metadata/practices.html *A good build file (for gump) is a simple build file* You know, I so agree! All Gump ought need is compile jar -- and it if wouldn't destroy Stefan's ant regression testing tool I'd be tempted to have Gump write the build script on the fly, from the information in the metadata, and forget any complex build tools. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
