Bug 29870 - Need a way to specify proxyHost and proxyPort to javadoc task
Summary: Need a way to specify proxyHost and proxyPort to javadoc task
Status: NEW
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.6.1
Hardware: All All
: P3 enhancement with 5 votes (vote)
Target Milestone: ---
Assignee: Ant Notifications List
Keywords: PatchAvailable
Depends on:
Reported: 2004-06-30 13:44 UTC by Mike Hanafey
Modified: 2009-07-31 05:25 UTC (History)
2 users (show)

pass proxy settings to javadoc tool (3.24 KB, patch)
2007-03-28 06:12 UTC, Thomas Kappen
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Hanafey 2004-06-30 13:44:38 UTC
<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

As a workaround, I just renamed the javadoc program, and added a script that
calls the renamed javadoc with the added arguments.
Comment 1 Ray Roberts 2004-07-20 03:42:14 UTC
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...
Comment 2 Mike Hanafey 2004-08-10 19:16:24 UTC
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.
Comment 3 Steve Loughran 2004-08-11 09:07:42 UTC
1. if javadoc runs in then ant process the <setproxy> task will do the work for 

2. somehow, the build file is going to need to be modified. 
Comment 4 Stephen R. Saucier 2005-10-03 19:29:42 UTC
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" /> 
<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:
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?
Comment 5 Matt Benson 2005-10-03 21:52:01 UTC
(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.
Comment 6 Steve Loughran 2005-10-10 11:27:18 UTC
If you use java1.5, set javadoc the JVM arg 

and have the JVM work it out for itself...
Comment 7 Thomas Kappen 2007-03-28 06:12:32 UTC
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:

Hi hope this patch will be merged into the Ant source tree.

What do you think?

Comment 8 Dominique Devienne 2007-03-28 06:32:37 UTC
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
Comment 9 Thomas Kappen 2007-03-28 06:54:14 UTC
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.
Comment 10 Dominique Devienne 2007-03-28 07:43:09 UTC
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
Comment 11 Thomas Kappen 2007-03-29 00:45:31 UTC
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.
Comment 12 Steve Loughran 2007-03-29 02:22:47 UTC
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