Maven ne parvient pas à trouver l'artefact local

Question

Occasionnellement, maven se plaint qu'une dépendance particulière, qui est construite et empaquetée localement, ne peut être trouvée dans le dépôt local lors de la construction d'un autre projet qui l'a comme dépendance. Nous obtenons une erreur du type :

Échec de l'exécution de l'objectif sur le projet X : Impossible de résoudre les dépendances pour le projet X : Impossible de trouver Y dans [référentiel archiva] a été mis en cache dans le référentiel local, la résolution ne sera pas réessayée avant que l'intervalle de mise à jour interne ne se soit écoulé ou que les mises à jour soient forcées ->.

Où X est le projet en cours de construction, et Y est l'artefact supposé manquant. Si vous regardez dans le référentiel local, l'artefact est là. Cet artefact n'est jamais installé dans notre référentiel archiva, donc le problème est purement basé dans le référentiel local.

Nous avons essayé différents profils dans settings.xml, et bien sûr "mvn -U". Ni l'un ni l'autre ne sont utiles, et ils ne devraient pas l'être puisque cet artefact ne va jamais plus loin que le dépôt local.

Les deux seules choses qui semblent fonctionner sont d'attendre un temps très long jusqu'à ce que maven devienne intelligent, ou de supprimer complètement le dépôt local. L'option d'attente est probablement liée à l'intervalle de mise à jour susmentionné.

Nous avons rencontré ce problème avec maven 3.0.2 et 3.0.3. Nous utilisons Archiva 1.0.3 (mais là encore, cela ne devrait pas être un facteur). Toute aide serait grandement appréciée.

Answer 1

Le repo Maven local suit l'origine des artefacts en utilisant un fichier nommé "_maven.repositories" dans le répertoire des artefacts. Après l'avoir supprimé, la construction a fonctionné. Cette réponse a réglé le problème pour moi.

Answer 2

Comme les options proposées ici n'ont pas fonctionné pour moi, je vais vous expliquer comment j'ai résolu le problème :

Mon projet a un projet parent (avec son propre pom.xml) qui a plusieurs modules enfants, dont l'un (A) a une dépendance avec un autre enfant (B). Lorsque j'ai essayé mvn package en A, ça n'a pas marché parce que B n'a pas pu être résolu.

Exécuter mvn install dans le répertoire parent a fait le travail. Après ça, je pouvais faire mvn package à l'intérieur de A et seulement alors il pourrait trouver B.

Answer 3

Même en mode hors ligne, maven vérifiera les dépôts distants s'il existe un marqueur _remote.repositories pour la dépendance. Si vous devez fonctionner en mode hors ligne, vous devrez peut-être supprimer ces fichiers.

La commande shell simple ci-dessous supprime ces fichiers marqueurs. Vous pouvez le faire en toute sécurité si vous n'utilisez que le mode hors ligne pour la machine. Je ne le ferais PAS sur une machine qui a besoin de télécharger des fichiers depuis le web.

J'ai utilisé cette stratégie sur un serveur de construction qui est déconnecté du web. Nous devons y transférer le référentiel, supprimer les fichiers marqueurs et ensuite exécuter en mode hors ligne.

Sous Linux / Unix, vous pouvez supprimer les fichiers marqueurs du dépôt distant de cette façon :

cd ~/.m2
find . -name "_remote.repositories" -type f -delete

Answer 4

Maven se souvient quand il n'a pas trouvé quelque chose. La clé est "la résolution ne sera pas réessayée jusqu'à ce que l'intervalle de mise à jour interne se soit écoulé ou que les mises à jour soient forcées ->"

La solution rapide est de supprimer votre sous-répertoire local "repository" pour l'artefact problématique - en supposant que vous avez résolu le problème avec celui-ci. :)

mvn -U forcera la mise à jour à partir du dépôt distant - encore une fois, en supposant que vous avez maintenant rempli le dépôt distant avec ledit artefact.

Answer 5

Lorsque cela m'est arrivé, c'était parce que j'avais aveuglément copié mon settings.xml à partir d'un modèle et qu'il contenait toujours le champ vide <localRepository/> élément. Cela signifie qu'il n'y a pas de dépôt local utilisé lors de la résolution des dépendances (bien que les artefacts installés soient toujours placés dans l'emplacement par défaut). Lorsque j'avais remplacé cet élément par <localRepository>${user.home}\.m2\repository</localRepository> ça a commencé à fonctionner.

Pour *nix, ce serait <localRepository>${user.home}/.m2/repository</localRepository> Je suppose.