Ein aus einer IDE gestarteter Gradle-Build kann eine andere Konfiguration verwenden als dasselbe Projekt aus einem Terminal. Vergleichen Sie vor dem Verdacht auf einen veralteten Proxyprozess das Gradle-Benutzerverzeichnis, die JVM und die Proxy-Eigenschaften jedes Starts.

Gradle dokumentiert JVM-Proxy-Eigenschaften

Eine Eigenschaftsdatei für HTTP- und HTTPS-Routen kann enthalten:

systemProp.http.proxyHost=203.0.113.10
systemProp.http.proxyPort=8080
systemProp.https.proxyHost=203.0.113.10
systemProp.https.proxyPort=8080
systemProp.http.nonProxyHosts=localhost|*.example.internal

Verwenden Sie den zugewiesenen Endpunkt; für zulässige Routen zu öffentlichen Repositories liefert die HTTP-Proxy-Liste mögliche Host-und-Port-Paare. Die HTTPS-Umgehungseigenschaft ist ebenfalls http.nonProxyHosts; https.nonProxyHosts zu erfinden ist keine dokumentierte Lösung. Die Host-Eigenschaften enthalten eine Adresse, keine vollständige Proxy-URL.

Das Exportieren von HTTP_PROXY in einer Shell beweist allein nicht, dass dieser JVM-Client es als Proxy-Richtlinie verwendet. Prüfen Sie die von der Anwendung unterstützten Eigenschaften.

Der Daemon erhält Build-Informationen

Die aktuelle Gradle-Dokumentation sagt, dass der Client Build-Informationen einschließlich Umgebungsvariablen an den Daemon sendet. Die pauschale Erklärung „Der Daemon erhält nie neue Umgebungsvariablen“ ist daher unzutreffend.

Einige JVM-Start-Eigenschaften, darunter Truststore-Eigenschaften, sind für eine laufende JVM unveränderlich. Ein anderes Java-Home oder eine geänderte Truststore-Startkonfiguration kann daher relevant sein, selbst wenn gewöhnliche Build-Umgebungswerte weitergegeben werden.

Vergleichen Sie die beiden Starts

Prüfen Sie, welche Gradle-Distribution und welche Java-Laufzeit die IDE auswählt. Prüfen Sie, ob sie dasselbe GRADLE_USER_HOME und dieselben Benutzereigenschaften wie das Terminal verwendet. Ein Proxy-Eintrag in der Konfiguration eines Benutzers zeigt nicht, was ein anderer Kontext geladen hat.

Wenn eine geänderte Startanforderung einen anderen Daemon benötigt, verwenden Sie die dokumentierten Daemon-Steuerungen für die betreffende Gradle-Version. Behandeln Sie das Stoppen von Daemons nicht als Ersatz für die Suche nach einer falschen Eigenschaft oder einer fehlenden Konfigurationsdatei.

Ermitteln Sie schließlich die fehlgeschlagene Anfrage. Wrapper-Downloads, die Auflösung von Build-Abhängigkeiten und Anfragen aus abgezweigten Anwendungs- oder Testprozessen sind nicht automatisch derselbe Netzwerkkontext. Prüfen Sie den Prozess, der die Anfrage stellt, bevor Sie erwarten, dass eine Gradle-Eigenschaft ihn steuert.

Ähnliche Artikel