De onde obtén Gradle as súas configuracións de proxy

Segue as propiedades de proxy da JVM de Gradle, a configuración do cartafol persoal e o contorno do cliente en vez de supoñer que o daemon sempre ignora as variables novas.

Unha compilación de Gradle iniciada desde un IDE pode usar unha configuración distinta da do mesmo proxecto iniciado desde un terminal. Antes de culpar un proceso de proxy antigo, compara o cartafol persoal de Gradle, a JVM e as propiedades de proxy de cada inicio.

Gradle documenta as propiedades de proxy da JVM

Para rutas HTTP e HTTPS, un ficheiro de propiedades pode conter:

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 o extremo asignado; para rutas permitidas a repositorios públicos, a lista de proxies HTTP ofrece pares candidatos de host e porto. A propiedade para evitar HTTPS tamén é http.nonProxyHosts; inventar https.nonProxyHosts non é a solución documentada. As propiedades do host conteñen un enderezo, non unha URL completa de proxy.

Exportar HTTP_PROXY nun shell non proba por si só que este cliente JVM o use como política de proxy. Comproba as propiedades admitidas pola aplicación.

O daemon si recibe información da compilación

A documentación actual de Gradle di que o cliente envía ao daemon información da compilación, incluídas as variables de contorno. Polo tanto, a explicación xeral «o daemon nunca recibe novas variables de contorno» é inexacta.

Algunhas propiedades de inicio da JVM, incluídas as do almacén de confianza, son inmutables para unha JVM en execución. Un Java home ou unha configuración inicial do almacén de confianza cambiados poden importar aínda que se transmitan os valores normais do contorno de compilación.

Compara os dous inicios

Comproba que distribución de Gradle e que runtime de Java escolle o IDE. Comproba se usa o mesmo GRADLE_USER_HOME e as propiedades de usuario que o terminal. Unha entrada de proxy na configuración dun usuario non establece o que cargou outro contexto.

Se un requisito de inicio cambiado precisa outro daemon, usa os controis documentados do daemon para a versión de Gradle correspondente. Non trates deter daemons como substituto para atopar unha propiedade incorrecta ou un ficheiro de configuración ausente.

Por último, identifica a solicitude que fallou. As descargas do Wrapper, a resolución de dependencias da compilación e as solicitudes de procesos bifurcados da aplicación ou das probas non son automaticamente un único contexto de rede. Verifica o proceso que fai a solicitude antes de esperar que unha propiedade de Gradle o controle.

Artigos relacionados