Skąd Gradle pobiera ustawienia serwera proxy

Prześledź właściwości proxy JVM Gradle, ustawienia katalogu domowego użytkownika i środowisko klienta, zamiast zakładać, że daemon zawsze ignoruje nowe zmienne.

Kompilacja Gradle uruchomiona z IDE może korzystać z innej konfiguracji niż ten sam projekt uruchomiony w terminalu. Zanim obwinisz stary proces proxy, porównaj katalog domowy Gradle, JVM i właściwości proxy używane przy każdym uruchomieniu.

Gradle dokumentuje właściwości proxy JVM

Plik właściwości dla tras HTTP i HTTPS może zawierać:

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

Użyj przydzielonego punktu końcowego; dla dozwolonych tras do publicznych repozytoriów lista serwerów proxy HTTP podaje kandydackie pary hosta i portu. Właściwość omijania HTTPS to również http.nonProxyHosts; wymyślenie https.nonProxyHosts nie jest udokumentowaną poprawką. Właściwości hosta zawierają adres, a nie pełny URL serwera proxy.

Samo wyeksportowanie HTTP_PROXY w powłoce nie dowodzi, że ten klient JVM używa go jako swojej polityki proxy. Sprawdź właściwości obsługiwane przez aplikację.

Daemon otrzymuje informacje o kompilacji

Aktualna dokumentacja Gradle mówi, że klient wysyła daemonowi informacje o kompilacji, w tym zmienne środowiskowe. Ogólne wyjaśnienie „daemon nigdy nie otrzymuje nowych zmiennych środowiskowych” jest więc nieścisłe.

Niektóre właściwości startowe JVM, w tym właściwości magazynu zaufania, są niezmienne dla działającej JVM. Zmieniony Java home lub konfiguracja startowa magazynu zaufania może więc mieć znaczenie, nawet gdy zwykłe wartości środowiska kompilacji są przekazywane.

Porównaj oba uruchomienia

Sprawdź, którą dystrybucję Gradle i środowisko uruchomieniowe Java wybiera IDE. Sprawdź, czy używa tego samego GRADLE_USER_HOME i właściwości użytkownika co terminal. Wpis proxy w konfiguracji jednego użytkownika nie mówi, co załadował inny kontekst.

Jeśli zmienione wymaganie startowe potrzebuje innego daemona, użyj udokumentowanych elementów sterujących daemonem dla odpowiedniej wersji Gradle. Nie traktuj zatrzymywania daemonów jako zamiennika znalezienia błędnej właściwości lub brakującego pliku konfiguracyjnego.

Na końcu wskaż żądanie, które się nie powiodło. Pobieranie Wrappera, rozwiązywanie zależności kompilacji i żądania procesów rozwidlonej aplikacji lub testów nie są automatycznie jednym kontekstem sieciowym. Sprawdź proces wykonujący żądanie, zanim oczekujesz, że właściwość Gradle będzie nim sterować.

Powiązane artykuły