Le proxy de dépôt de Maven peut récupérer des dépendances sans configurer une requête HTTP effectuée par un test. Configurez le client dans la JVM de test.

Si ce client respecte les propriétés de proxy HTTPS de Java, placez ce fragment dans l'élément configuration du greffon Surefire concerné :

<systemPropertyVariables>
  <https.proxyHost>proxy.example</https.proxyHost>
  <https.proxyPort>8080</https.proxyPort>
</systemPropertyVariables>

Remplacez le point de terminaison d'exemple. Pour les tests vers des destinations publiques où des intermédiaires publics sont autorisés, la liste de proxys HTTP propose des candidats d'hôte et de port. L'hôte et le port sont des valeurs distinctes ; choisissez la famille de propriétés adaptée au schéma de destination et à la bibliothèque. En revanche, un client construit avec un objet proxy explicite a besoin de sa propre interface de configuration.

Surefire exécute généralement les tests dans une JVM forkée. Toutes les options utilisées pour lancer Maven n'atteignent pas ce processus. La détection de proxy système sensible au démarrage a besoin de son option sur la JVM de test au démarrage. Même lorsque les tests partagent un processus, une bibliothèque peut ignorer les propriétés de proxy Java par défaut.

Gardez les destinations internes directes couvertes par une règle de contournement adaptée, l'authentification du proxy distincte de l'authentification de destination et la vérification des certificats activée. Désactiver le fork change l'exécution des tests ; changer un miroir de dépendances change la résolution du dépôt. Ni l'un ni l'autre ne fournit une route de client de test manquante. Copier toutes les propriétés système peut aussi exposer des secrets.

En cas d'échec persistant, notez la JVM de test, la bibliothèque HTTP, la cible, le proxy choisi et la première étape en échec. Ces observations orientent vers la configuration du test tout en laissant compréhensibles les téléchargements de dépôt qui fonctionnent.

Articles similaires