Maven ne parvient pas à trouver l'artefact local


107

Parfois, maven se plaint qu'une dépendance particulière, qui est construite et empaquetée localement, ne peut pas être trouvée dans le référentiel local lors de la construction d'un autre projet qui l'a comme dépendance. Nous obtenons une erreur comme:

Échec de l'exécution de l'objectif sur le projet X: impossible de résoudre les dépendances pour le projet X: l'échec de la recherche de Y dans [référentiel archiva] a été mis en cache dans le référentiel local, la résolution ne sera pas tentée de nouveau tant que l'intervalle de mise à jour de l'interne ne sera pas écoulé ou que les mises à jour sont 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 faire de bien, ni ne le devraient car cet artefact ne va jamais plus loin que le référentiel local.

Les deux seules choses qui semblent fonctionner sont d'attendre très longtemps jusqu'à ce que maven s'intensifie, ou de supprimer complètement le référentiel local. Vraisemblablement, l'option d'attente est 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 encore une fois, cela ne devrait pas être un facteur). Toute aide serait grandement appréciée.


1
Maven enregistre-t-il quelque chose pendant ou juste avant «l'attente»? Ie tente-t-il de se connecter à un référentiel inaccessible? En outre, les artefacts problématiques sont-ils "-SNAPSHOT"?
noahlz

Maven n'enregistre rien d'autre que l'erreur que j'ai mentionnée ci-dessus. Et oui, c'est une dépendance d'instantané.
user1686620


1
Avez-vous installé le package de génération avant d'essayer de générer le deuxième projet?
khmarbaise

3
J'aime la façon dont le message d'erreur est une répétition, pas une phrase grammaticalement correcte. De cette façon, nous ne savons pas avec certitude s'il ne peut pas trouver Y ou si Y a été mis en cache localement, ou les deux. Quoi qu'il en soit, j'ai un problème similaire. J'ai pu le résoudre avec l'option -U car mes dépendances sont dans le repo interne de mon entreprise. Pourquoi les artefacts dont vous avez besoin ne sont-ils pas déployés dans le référentiel interne de votre entreprise?
jyoungdev

Réponses:


77

Le référentiel Maven local suit l'origine des artefacts à l'aide d'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ésolu le problème pour moi.


26
Pour moi, c'était un fichier nommé "_remote.repositories". Je l'ai enlevé et cela a fonctionné! Merci pour les astuces!
perbellinio

2
Thx le fichier nommé _remote.repositories était également présent. cela m'est arrivé lorsque notre lien cesse d'avoir une connexion réseau afin qu'il ne
puisse

1
La solution fournie fonctionne. Cependant, je suis intéressé par la raison pour laquelle ce problème se produit. Quelqu'un pourrait-il me fournir une explication rapide? Dois-je faire quelque chose différemment?
Janothan

Si vous souhaitez contourner cette vérification d'origine une fois (sans supprimer les métafichiers), essayez de passer aether.enhancedLocalRepository.trackingFilename=some_dummy_file_nameau processus de résolution des dépendances; Le moyen le plus simple est d'ajouter une propriété système -D à la commande d'appel.
Janaka Bandara

@Janothan IMO le lien dans la réponse fournit une assez bonne explication :)
Janaka Bandara

40

Comme les options ici n'ont pas fonctionné pour moi, je partage comment je l'ai résolu:

Mon projet a un projet parent (avec son propre pom.xml) qui a de nombreux modules enfants, dont l'un (A) a une dépendance à un autre enfant (B). Quand j'ai essayé mvn packageen A, cela n'a pas fonctionné car B ne pouvait pas être résolu.

L'exécution mvn install dans le répertoire parent a fait le travail. Après cela, je pourrais faire à l' mvn packageintérieur de A et alors seulement il pourrait trouver B.


3
MERCI! cela me rendait fou. mvn clean package jboss-as: deploy fonctionnait lorsque je les exécutais sur une seule ligne, mais pas lorsque je les faisais séparément.
PMorganCA

18

Même en mode hors ligne, maven vérifiera les référentiels 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 simple commande shell ci-dessous supprime ces fichiers de marqueurs. Cette opération est sûre si vous n'utilisez que le mode hors ligne pour la machine. Je ne ferais PAS cela sur une machine qui a besoin d'extraire des fichiers du Web.

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

Sous Linux / Unix, vous pouvez supprimer les fichiers de marqueurs du référentiel distant de cette manière:

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

1
Cette solution a fonctionné pour moi, pour une dépendance que j'ai copiée à partir d'un autre ordinateur qui n'est pas disponible dans un référentiel central. La commande manque cependant quelques caractères. Voici la commande complète: find. -name "_remote.repositories" -type -f -delete
Hans Deragon

2
Ou, au lieu de supprimer, vous devriez être en mesure de "tromper" Maven pour ne pas regarder le _remote.repositoriesfichier en le passant -Daether.enhancedLocalRepository.trackingFilename=some_dummy_file_nameau processus. (Je n'ai pas essayé une version réelle de Maven, mais fonctionne lors de l'invocation de Maven par programme; le premier devrait donc également fonctionner)
Janaka Bandara

1
J'ai fait cette recherche et j'ai supprimé des dépendances spécifiques (jars) non trouvées par Maven, car elles étaient répertoriées et gérables jusqu'à (<10). Cela était dû à une mauvaise configuration pointant vers un Nexus distant actuellement non disponible (si j'ai bien compris ..). Il n'est donc pas nécessaire de balayer tous les dépôts pour les supprimer. Quoi qu'il en soit, cette solution a sauvé la mise. Ça marche pour moi.
Diego1974

9

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

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


6
$ {user.home} \. m2 \ repository est la valeur par défaut donc la suppression de la balise vide devrait fonctionner de la même manière.
Luis Muñoz

9

Maven se souvient quand il n'a pas trouvé quelque chose. La clé est "la résolution ne sera pas tentée à nouveau jusqu'à ce que l'intervalle de mise à jour de l'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 du problème - en supposant que vous avez résolu le problème avec lui. :)

mvn -U forcera la mise à jour depuis le référentiel distant - encore une fois, en supposant que vous ayez maintenant rempli remote avec ledit artefact.


2

Attrapez tout. Lorsque les solutions mentionnées ici ne fonctionnent pas (dans mon cas), supprimez simplement tout le contenu du dossier / répertoire '.m2' et faites mvn clean install.


2

Si vous avez <repositories/>défini dans votre pom.xml, apparemment, votre référentiel local est ignoré.


1

Même moi, j'ai rencontré ce problème et l'ai résolu de 2 façons:

1) Dans votre IDE, sélectionnez le projet et nettoyez tous les projets, puis installez toutes les dépendances maven en cliquant avec le bouton droit sur le projet -> allez dans maven et mettez à jour les dépendances du projet, sélectionnez tous les projets à la fois pour les installer. Une fois que cela est fait, exécutez le projet particulier

2) Sinon, ce que vous pouvez faire est de vérifier dans le pom.xml les dépendances pour lesquelles vous obtenez une erreur et "mvn clean install" ces projets dépendants en premier et les dépendances install maven du projet actuel dans lequel vous rencontrez un problème. Ainsi, les dépendances du projet local seront construites et des fichiers JAR seront créés.


0

Je rencontre le même problème lorsque mon nouveau projet dépend du jar oracle jdbc (que j'ai installé dans mon référentiel local et fonctionne bien pour d'autres projets). J'ai essayé l'option -U, en supprimant le fichier .lastupdate ou tout le répertoire et en le téléchargeant à nouveau, mais cela n'a pas fonctionné. enfin, j'ai supprimé le répertoire et l'ai réinstallé localement, cela fonctionne.


0

L'une des erreurs que j'ai trouvées autour de Maven est lorsque je place mon fichier settings.xml dans le mauvais répertoire. Il doit être dans le dossier .m2 sous votre répertoire personnel. Assurez-vous qu'il est au bon endroit (avec settings-security.xml si vous l'utilisez).


0

J'avais DependencyResolutionExceptiondans Ubuntu Linux lorsque j'ai installé des artefacts locaux via un script shell. La solution était de supprimer les artefacts locaux et de les réinstaller «manuellement» - en appelant mvn install:install-filevia le terminal.


0

Cela s'est produit parce que j'avais httpau lieu de httpscela:

<repository>
    <id>jcenter</id>
    <name>jcenter-bintray</name>
    <url>https://jcenter.bintray.com</url>
</repository>

0

vérifiez si votre artefact Y a un emballage défini sur "jar". Si vous l'avez défini comme "guerre" par erreur ou par copier-coller, cela montrera que cet étrange "a été mis en cache dans le référentiel local, la résolution ne sera pas tentée de nouveau jusqu'à ce que l'intervalle de mise à jour de l'interne se soit écoulé ou que les mises à jour soient forcées". Je m'attendrais à quelque chose comme "l'artefact Y est la guerre, le type de pot est attendu".


-1

J'ai eu la même erreur d'une cause différente: j'avais créé un POM de démarrage contenant nos dépendances de "bonne pratique", et je l'avais construit et installé localement pour le tester. Je pouvais le «voir» dans le repo, mais un projet qui l'utilisait a obtenu l'erreur ci-dessus. Ce que j'avais fait, c'était de régler le POM de départ sur pom, donc il n'y avait pas de JAR. Maven avait tout à fait raison de dire que ce n'était pas dans Nexus - mais je ne m'attendais pas à ce que ce soit le cas, donc l'erreur était, euh, inutile. Le changement du POM de démarrage en emballage normal et la réinstallation ont résolu le problème.


Cette réponse aurait probablement été meilleure comme commentaire, car ce n'est pas une réponse directe à la question.
00prometheus le
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.