Mistä Gradle saa välityspalvelinasetuksensa

Seuraa Gradlen JVM-välityspalvelinominaisuuksia, käyttäjän kotihakemiston asetuksia ja asiakasympäristöä sen sijaan, että oletat demonin aina ohittavan uudet muuttujat.

IDE:stä käynnistetty Gradle-koonti voi käyttää eri asetuksia kuin sama projekti päätteestä käynnistettynä. Vertaa kunkin käynnistyksen Gradle-käyttäjäkotia, JVM:ää ja välityspalvelinominaisuuksia ennen kuin syytät vanhaa välityspalvelinprosessia.

Gradle dokumentoi JVM-välityspalvelinominaisuudet

HTTP- ja HTTPS-reiteillä ominaisuustiedosto voi sisältää:

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

Käytä sinulle annettua päätepistettä; sallituilla julkisten arkistojen reiteillä HTTP-välityspalvelinluettelo antaa ehdokaspari-isäntiä ja portteja. HTTPS-ohituksen ominaisuus on myös http.nonProxyHosts; https.nonProxyHosts:n keksiminen ei ole dokumentoitu korjaus. Isäntäominaisuudet sisältävät osoitteen, eivät täydellistä välityspalvelimen URL-osoitetta.

HTTP_PROXY:n vieminen komentotulkkiin ei yksin todista, että tämä JVM-asiakas käyttää sitä välityspalvelinkäytäntönään. Tarkista sovelluksen tukemat ominaisuudet.

Daemoni saa koontitiedot

Gradlen nykyinen dokumentaatio kertoo, että asiakas lähettää koontitiedot, ympäristömuuttujat mukaan lukien, daemonille. Siksi yleinen selitys ”daemon ei koskaan saa uusia ympäristömuuttujia” on epätarkka.

Jotkin JVM:n käynnistysominaisuudet, kuten luottamusvaraston ominaisuudet, ovat muuttumattomia käynnissä olevalle JVM:lle. Muuttunut Java-kotihakemisto tai luottamusvaraston käynnistysasetus voi siis vaikuttaa, vaikka tavalliset koontiympäristön arvot välitetään.

Vertaa kahta käynnistystä

Tarkista, minkä Gradle-jakelun ja Java-ajonaikaisen ympäristön IDE valitsee. Tarkista, käyttääkö se samaa GRADLE_USER_HOME-asetusta ja käyttäjäominaisuuksia kuin pääte. Yhden käyttäjän asetusten välityspalvelinmerkintä ei kerro, mitä toinen konteksti latasi.

Jos muuttunut käynnistysvaatimus tarvitsee eri daemonin, käytä kyseisen Gradle-version dokumentoituja daemon-hallintatoimintoja. Älä pidä daemonien pysäyttämistä väärän ominaisuuden tai puuttuvan asetustiedoston etsimisen korvikkeena.

Tunnista lopuksi epäonnistunut pyyntö. Wrapper-lataukset, koontiriippuvuuksien ratkaisu ja haarautettujen sovellus- tai testiprosessien pyynnöt eivät automaattisesti kuulu samaan verkkokontekstiin. Varmista pyynnön tekevä prosessi ennen kuin odotat Gradle-ominaisuuden ohjaavan sitä.

Aiheeseen liittyvät artikkelit