Lors du téléchargement des dépendances par maven, l'une d'elles échoue en raison de problèmes de réseau:
Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-failsafe-plugin/2.16/maven-failsafe-plugin-2.16.pom Plugin org.apache.maven.plugins:maven-failsafe-plugin:2.16 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-failsafe-plugin:jar:2.16
Je voudrais réessayer n fois où n sera configurable. Comment puis-je faire cela?
4 Réponses :
Permettez-moi de suggérer une solution alternative:
Configurez un serveur Nexus ou Artifactory dans votre réseau local. Laissez vos builds le parcourir. Il mettra en cache tous les artefacts qui ont été utilisés afin que le risque de rencontrer des problèmes de réseau diminue considérablement.
Eh bien, nous avons un serveur Nexus dans notre réseau local et il y a toujours ce problème. Donc, pour moi, la solution la plus simple sera de simplement réessayer le téléchargement.
Le problème vient donc de la connexion du Nexus au monde extérieur?
C'est peut-être le cas, mais TBH je voudrais simplement réessayer de maven si c'est possible. Je n'ai pas accès au serveur Nexus par moi-même.
Je comprends, mais ce n'est probablement pas possible (je ne suis pas sûr, cependant). Il peut cependant être plus judicieux de rechercher le problème de réseau d'origine. Je n'ai jamais rencontré d'échec de téléchargement de MavenCentral.
Maven semble avoir un problème avec la récupération des dépendances en raison de la fermeture des connexions persistantes. Cela se produit lorsque vous exécutez mvn dans un environnement de construction (Docker, Azure, Jenkins) et que la construction est plutôt longue (> 5 minutes).
Utilisez cet indicateur maven pour désactiver le keep-alive pour les requêtes HTTP et voyez si cela résout votre problème:
mvn -Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false clean package
D'autres ont également mentionné l'utilisation de cet indicateur:
-Dmaven.wagon.http.pool=false
Par exemple
-Dhttp.keepAlive=false
Il est tôt pour le dire avec certitude, mais il semble que la suggestion http.keepAlive a permis à notre équipe de surmonter un problème récurrent avec un problème de résolution de dépendance spécifique. Nous aimerions toujours savoir pourquoi le problème a commencé à se produire en général, peut-être un problème de réseau ou quelque chose du genre, mais l'option -X ne semblait pas vraiment nous donner les informations nécessaires pour creuser pas plus loin.
jpierson - faites-moi savoir si vous découvrez pourquoi cela se produit. Je suis également curieux de connaître la cause de la réinitialisation de la connexion.
J'ai eu un problème similaire dans Gitlab CI / CD. Cela semble avoir résolu le problème:
-Dmaven.wagon.http.retryHandler.count=3
Depuis la version 3.2, le gestionnaire de nouvelles tentatives peut être configuré avec system propriétés:
...
maven.wagon.http.retryHandler.count= nombre de tentatives pour les implémentations par défaut ou standard.
D'autres paramètres du client HTTP sont décrits ici: https: / /maven.apache.org/wagon/wagon-providers/wagon-http/
Dans le cas où vous exécutez dans un environnement derrière un NAT, avec un court timeout NAT, une possibilité est de définir -Dmaven.wagon.httpconnectionManager.ttlSeconds = 25 au lieu de désactiver le http regroupement de connexions dans maven.
Ceci est utilisé dans le dépôt apache / pulsar:
env: MAVEN_OPTS: -Dmaven.wagon.httpconnectionManager.ttlSeconds=25 -Dmaven.wagon.http.retryHandler.count=3
Dans le dernier commentaire de WAGON-545 , il dit "Les utilisateurs Azure doivent définir la durée de vie sur 240 secondes ou moins."