Waar Gradle sy proxy-instellings kry
Volg Gradle se JVM-proxy-eienskappe, gebruiker-tuismap-instellings en kliëntomgewing eerder as om aan te neem dat die daemon altyd nuwe veranderlikes ignoreer.
’n Gradle-bou wat vanuit ’n IDE begin word, kan ’n ander opstelling gebruik as dieselfde projek vanuit ’n terminaal. Vergelyk die Gradle-gebruikerstuis, JVM en proxy-eienskappe van elke begin voordat jy ’n ou proxyproses blameer.
Gradle dokumenteer JVM-proxy-eienskappe
Vir HTTP- en HTTPS-roetes kan ’n eienskappelêer die volgende bevat:
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
Gebruik jou toegewese eindpunt; vir toegelate openbare-bewaarplekroetes verskaf die HTTP-proxyl lys kandidaatgasheer en poortpare. Die HTTPS-omseil-eienskap is ook http.nonProxyHosts; om https.nonProxyHosts uit te dink is nie die gedokumenteerde oplossing nie. Gasheereienskappe bevat ’n adres, nie ’n volledige proxy-URL nie.
Om HTTP_PROXY in ’n dop uit te voer bewys op sigself nie dat hierdie JVM-kliënt dit as sy proxybeleid gebruik nie. Kontroleer die eienskappe wat die toepassing ondersteun.
Die daemon ontvang wel bou-inligting
Huidige Gradle-dokumentasie sê dat die kliënt bou-inligting, insluitend omgewingsveranderlikes, aan die daemon stuur. “Die daemon ontvang nooit nuwe omgewingsveranderlikes nie” is dus ’n onakkurate algemene verduideliking.
Sommige JVM-begin-eienskappe, insluitend truststore-eienskappe, is onveranderlik vir ’n lopende JVM. ’n Veranderde Java-tuismap of truststore-beginopstelling kan dus saak maak selfs wanneer gewone bou-omgewingswaardes deurgegee word.
Vergelyk die twee beginprosesse
Kontroleer watter Gradle-verspreiding en Java-looptyd die IDE kies. Kontroleer of dit dieselfde GRADLE_USER_HOME en gebruikerseienskappe as die terminaal gebruik. ’n Proxy-inskrywing in een gebruiker se opstelling bewys nie wat ’n ander konteks gelaai het nie.
As ’n veranderde beginvereiste ’n ander daemon benodig, gebruik die gedokumenteerde daemonbeheer vir die betrokke Gradle-weergawe. Moenie daemons stop as plaasvervanger vir die vind van ’n verkeerde eienskap of ontbrekende konfigurasielêer beskou nie.
Identifiseer laastens die versoek wat misluk het. Wrapper-aflaaie, bouafhanklikheidsresolusie en versoeke deur gevurkte toepassing- of toetsprosesse is nie outomaties een netwerkkonteks nie. Verifieer die proses wat die versoek maak voordat jy verwag dat ’n Gradle-eienskap dit beheer.