Herunterladen über einen Proxy mit der get-Task von Ant
Den Proxy vor dem Download durch Ant setzen, mit getrennten Zugangsdaten für Vermittler und Download-Server.
Die get-Task von Ant verwendet die Netzwerkkonfiguration der JVM, in der Ant läuft. Ein Proxy kann vor dem Download mit setproxy gesetzt werden:
<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>Namen und Port sind Beispiele. Für eine Anfrage nach einem öffentlichen Artefakt, die öffentliche Proxys nutzen darf, nehmen Sie einen HTTP-Endpunkt aus der HTTP-Proxy-Liste. Die Ausnahmeliste verwendet senkrechte Striche, keine Kommas. Nehmen Sie nur Ziele auf, die tatsächlich direkt gehen sollen; ein interner Download über einen externen Proxy kann fehlschlagen, auch wenn der Proxy korrekt funktioniert.
Die Reihenfolge zählt. Setzen Sie die Proxy-Task vor den get-Vorgang, sei es im selben Target oder in einem vorausgehenden Target. Eine Konfiguration nach Beginn des Downloads kann diese Verbindung nicht mehr ändern.
Es gibt zwei mögliche Anmeldungen. Die Attribute proxyuser und proxypassword von setproxy betreffen den Vermittler. Die Attribute username und password von get betreffen den Download-Server. Das Proxy-Konto an get zu übergeben macht daraus keine Proxy-Authentifizierung. Unterstützung und Einschränkungen der Authentifizierung hängen auch vom JDK und vom geforderten Verfahren des Proxys ab.
Die Einstellung gilt für die gesamte JVM. Sie eignet sich für Ant-Tasks, die diesen Netzwerkpfad nutzen, konfiguriert aber nicht jedes externe Programm, das ein Build startet. Sie kann auch spätere Netzwerk-Tasks im selben Ant-Prozess beeinflussen. Standortspezifische Endpunkte und Geheimnisse gehören in die lokale Konfiguration des Builds, statt das Konto eines Entwicklers in ein gemeinsames Target einzubetten.
Wenn das Betriebssystem die gewünschte Route bereits bereitstellt, dokumentiert Ant außerdem -autoproxy für die Betriebssystem-Erkennung auf unterstützten Java-Laufzeiten. Das ist eine alternative Quelle für Routing-Konfiguration. Für ein Build, das einen expliziten Endpunkt braucht, macht die obige Task die gewählte Route und ihren Zeitpunkt sichtbar.