I am seeing a number of problems with the gump builds on lsd and on gump.covalent.net.
It looks like some builds are trying to get resources from the Internet and are failing there :
example : *rhino* [1] [2]
yesterday, I also noticed a failure of the build of *commons-codec* hanging 1 hour in the javadoc generation on lsd.
The build.xml of jakarta-commons/codec contains the following line in the javadoc task :
link="http://java.sun.com/products/jdk/1.3/docs/api/";>
Another subproject of jakarta-commons had the same problem too.
Can it be that javadoc then visits the sun web site to find out which packages are present under http://java.sun.com/products/jdk/1.3/docs/api/ ?
I would guess so.
The part of the build which is causing the problem is here : http://lxr.mozilla.org/mozilla/source/js/rhino/toolsrc/build.xml
I am thinking of contacting the rhino team, and asking them to do the following
1) create a property containing the full path of the source zip the build downloads from Sun
${nest}/${build.dir}/swingExSrc.zip
2) test for the availability of the file before doing the download, and only do the download if the file is not present locally.
3) then in gump we could define the location of this swingExSrc.zip in the descriptor for rhino,
and add this file to the list of prerequisites for a gump instance doing a full build.
Maybe add a small gump module containing a packaged project for this one too ?
Do others think this is a good approach ?
Antoine
Footnotes :
[1] http://lsd.student.utwente.nl/gump/rhino/rhino.html [2] http://gump.covalent.net/log/rhino.html
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
