Où Gradle trouve ses paramètres de proxy

Suivez les propriétés de proxy de la JVM de Gradle, les paramètres du répertoire utilisateur et l’environnement du client au lieu de supposer que le daemon ignore toujours les nouvelles variables.

Une compilation Gradle lancée depuis un IDE peut utiliser une configuration différente du même projet lancé depuis un terminal. Avant d’accuser un ancien processus proxy, comparez le répertoire utilisateur de Gradle, la JVM et les propriétés de proxy utilisées par chaque lancement.

Gradle documente les propriétés de proxy de la JVM

Pour les routes HTTP et HTTPS, un fichier de propriétés peut contenir :

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

Utilisez le point de terminaison attribué ; pour les routes autorisées vers des dépôts publics, la liste des proxys HTTP fournit des couples hôte-port candidats. La propriété de contournement HTTPS est aussi http.nonProxyHosts ; inventer https.nonProxyHosts n’est pas la correction documentée. Les propriétés d’hôte contiennent une adresse, pas une URL de proxy complète.

Exporter HTTP_PROXY dans un shell ne prouve pas à lui seul que ce client JVM l’utilise comme politique de proxy. Vérifiez les propriétés prises en charge par l’application.

Le daemon reçoit bien les informations de compilation

La documentation actuelle de Gradle indique que le client envoie au daemon les informations de compilation, y compris les variables d’environnement. L’affirmation générale « le daemon ne reçoit jamais de nouvelles variables d’environnement » est donc inexacte.

Certaines propriétés de démarrage de la JVM, notamment celles du magasin de confiance, sont immuables pour une JVM en cours d’exécution. Un Java home ou une configuration de démarrage du magasin de confiance modifiés peuvent donc compter même lorsque les valeurs normales de l’environnement de compilation sont transmises.

Comparez les deux lancements

Vérifiez quelle distribution Gradle et quel runtime Java l’IDE sélectionne. Vérifiez s’il utilise le même GRADLE_USER_HOME et les mêmes propriétés utilisateur que le terminal. Une entrée de proxy dans la configuration d’un utilisateur ne permet pas de savoir ce qu’un autre contexte a chargé.

Si une exigence de démarrage modifiée nécessite un autre daemon, utilisez les contrôles de daemon documentés pour la version de Gradle concernée. Ne considérez pas l’arrêt des daemons comme un substitut à la recherche d’une propriété incorrecte ou d’un fichier de configuration manquant.

Enfin, identifiez la requête qui a échoué. Les téléchargements du Wrapper, la résolution des dépendances de compilation et les requêtes de processus d’application ou de test bifurqués ne constituent pas automatiquement un seul contexte réseau. Vérifiez le processus qui émet la requête avant d’attendre qu’une propriété Gradle le contrôle.

Articles similaires