Ant's get task uses the networking configuration of the JVM running Ant. A proxy can be set before the download with setproxy:

<target name="download">
  <setproxy proxyhost="proxy.example.net"
            proxyport="8080"
            nonproxyhosts="localhost|127.*|*.internal.example.net"/>
  <get src="https://downloads.example.net/tool.zip"
       dest="tool.zip"/>
</target>

The names and port are examples. For a public artifact request permitted to use public proxies, take an HTTP endpoint from the HTTP proxy list. The bypass list uses vertical bars, not commas. Include only destinations that should actually go direct; an internal download routed to an external proxy can fail even when the proxy is working correctly.

Order matters. Put the proxy task before the get operation, whether that is in the same target or a prerequisite target. Configuring it after the download starts cannot change that connection.

There are two possible logins. The proxyuser and proxypassword attributes of setproxy concern the intermediary. The username and password attributes of get concern the download server. Supplying the proxy account to get does not turn it into proxy authentication. Authentication support and restrictions also depend on the JDK and the proxy's required mechanism.

The setting has JVM scope. It is suitable for Ant tasks using that networking path, but it does not configure every external executable a build launches. It can also affect later network tasks in the same Ant process. Keep site-specific endpoints and secrets in the build's local configuration rather than embedding one developer's account in a shared target.

If the operating system already supplies the intended route, Ant also documents -autoproxy for operating-system discovery on supported Java runtimes. That is an alternative source of routing configuration. For a build that needs an explicit endpoint, the task above makes the selected route and its timing visible.

Tënë sô zo