Problems with the gump builds on lsd and on gump.covalent.net - http access

[Antoine Lévy-Lambert <an...@antbuild.com>]

Hi,

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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org