Una build Gradle avviata da un IDE può usare una configurazione diversa dallo stesso progetto avviato da un terminale. Prima di attribuire il problema a un processo proxy obsoleto, confronta la home utente di Gradle, la JVM e le proprietà proxy usate da ciascun avvio.

Gradle documenta le proprietà proxy della JVM

Per i percorsi HTTP e HTTPS, un file delle proprietà può contenere:

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

Usa l’endpoint assegnato; per i percorsi consentiti verso repository pubblici, l’elenco dei proxy HTTP fornisce coppie candidate di host e porta. La proprietà per escludere HTTPS è anch’essa http.nonProxyHosts; inventare https.nonProxyHosts non è la correzione documentata. Le proprietà dell’host contengono un indirizzo, non un URL proxy completo.

Esportare HTTP_PROXY in una shell non dimostra da solo che questo client JVM lo usi come criterio proxy. Controlla le proprietà supportate dall’applicazione.

Il daemon riceve davvero le informazioni di build

La documentazione attuale di Gradle afferma che il client invia al daemon le informazioni di build, incluse le variabili d’ambiente. Quindi la spiegazione generale «il daemon non riceve mai nuove variabili d’ambiente» è imprecisa.

Alcune proprietà di avvio della JVM, comprese quelle del trust store, sono immutabili per una JVM in esecuzione. Un Java home diverso o una configurazione di avvio del trust store modificata può quindi essere importante anche quando i normali valori dell’ambiente di build vengono trasmessi.

Confronta i due avvii

Controlla quale distribuzione Gradle e quale runtime Java sceglie l’IDE. Controlla se usa lo stesso GRADLE_USER_HOME e le stesse proprietà utente del terminale. Una voce proxy nella configurazione di un utente non stabilisce cosa abbia caricato un altro contesto.

Se un requisito di avvio modificato richiede un daemon diverso, usa i controlli documentati del daemon per la versione Gradle interessata. Non considerare l’arresto dei daemon un sostituto della ricerca di una proprietà errata o di un file di configurazione mancante.

Infine, identifica la richiesta che è fallita. I download del Wrapper, la risoluzione delle dipendenze di build e le richieste dei processi applicativi o di test biforcati non sono automaticamente un unico contesto di rete. Verifica il processo che effettua la richiesta prima di aspettarti che una proprietà Gradle lo controlli.

Articoli correlati