Maven ne parvient pas à trouver l'artefact local

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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).

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.

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>

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".

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.