<javadoc><link> to sites behind a firewall either require the offline attribute and the inconvient local copy of the packagelist, or, if javadoc is invoked with "-J-DproxyHost=proxy.com -J-DproxyPort=3128", javadoc will fetch the package list behind the firewall. In some cases it might also be necessary to set a noProxyOn list, but I am not clear on the exact syntax. It would be nice if the javadoc task would provide a way to configure proxy settings. As a workaround, I just renamed the javadoc program, and added a script that calls the renamed javadoc with the added arguments.
You should be able to send in the following to the javadoc task: additionalparam="-J-DproxyHost=myproxyhost.com -J-DproxyPort=8080" Seems to be working for me...
Adding the 'additionalparam' attribute to the javadoc task works, but this means the build file must be modified. The upgrade would be a scheme where the setting was made external to the build file, given that the setting depends on a particular environment.
1. if javadoc runs in then ant process the <setproxy> task will do the work for you. 2. somehow, the build file is going to need to be modified.
I have a similar situation. I would like to specify the socksProxyHost and socksProxyPort for the javadoc command, and I can do so with the nested <arg value="-J-DsocksProxyHost=myhost.com" /> and <arg value="-J-DsocksProxyHost=8080" /> but this requires me putting my proxy information in my build file. This means my build will not work on machines that do not require a proxy configuration. The best I can do right now is to do something like suggested in comment #1: additionalparam="-J-DproxyHost=myproxyhost.com -J-DproxyPort=8080" and specifying the additional parameters as a property: additionalparam="${additionalparam}" but that doesn't really seem like the best solution. I would think ant should take the arguments to the ant jvm and pass them through javadoc, prefixed by -J?
(In reply to comment #4) > ... I would think ant should > take the arguments to the ant jvm and pass them through javadoc, prefixed by -J? :| why would you think that? Ant should do anything within reason, but I don't find the above desirable.
If you use java1.5, set javadoc the JVM arg java.net.useSystemProxies=true and have the JVM work it out for itself...
Created attachment 19828 [details] pass proxy settings to javadoc tool Hi there, the attached patch passes proxy settings to the javadoc commandline tool, which will be called from the <javadoc> ant task. Proxy settings are necessary if external javadoc resources should be linked with the generated javadoc, and the host resides behind a firewall. The proxy settings from the system properties must be explicitly passed to the javadoc commandline tool, since the tool cannot be run inside the same jvm as ant, and therefore a new jvm will be created for javadoc (refer to: http://ant.apache.org/manual/index.html) Hi hope this patch will be merged into the Ant source tree. What do you think? Cheers, Thomas
I think your build would be faster if you used linkoffline instead of link, and you wouldn't need proxy settings because then it doesn't need to "dial out". --DD
In deed, the build would be faster, but speed is not my intention. This issue raised to me as I tried to build an open source project, which uses link options to link against some external javadoc sites, like J2SE and JUnit. The build failed, because I am behind the firewall, and I have to use a proxy. Since I wont build the software not very often, and I don't like to modify the build script, and I don't like to download each external javadoc site to my location, I think it makes sense to enable proxy settings for the javadoc task. The patch is not a big thing, and gives in general more flexibility to developers. Therefore, I would say proxy is a useful feature for the javadoc task.
Sure. I don't disagree with you. But in practice, you work around the issue using linkoffline. And if you want to avoid downloading the packageList yourself, you can use <get> beforehand, which could then cache the packageList locally and only download it if missing or changed. But you could also create the packageList yourself, because you know which packages from 3rd parties you are using. The packageList doesn't need to be exhaustive, as long as it contains what you use. These are all practical work-arounds to your issue ;-) --DD
For all these workarounds I have to modify the scripts of the mentioned open source software. But I would like to build the software 'out of the box', without modifying any scripts, or to patch Ant myself. I think this is a straight forward approach. Further, for an occasional build, implementing a workaround means more effort for inexperienced developers, than waiting for the downloads of javadoc. Additionally, if a developer takes Ant as a black box, and he has set the proxy with Java system properties or the <setptoxy> task, he expects that each task will use the proxy settings, isn't he? Are there any arguments against a patch? Is it too much effort for you or the Ant team? Do you see risks or side effects? We are talking about an additional feature. Nobody HAS to use it. Everybody has the choice to improve the script for performance or usability.
I am in favour of a patch, and will put one in, though subtly different -there's a lot of duplication in the getProperty("http.Something"), check for null and set in the other system. I think we could do the same with a propertySet passing http.* https.* and socks.* down. -I'd like the code to be general to all exe/java code, or maybe placed in some ProxyHelper class that helps with proxy setup. The problem is broader than just javadoc.