Maven findet kein lokales Artefakt

Gelegentlich beschwert sich maven, dass eine bestimmte Abhängigkeit, die lokal erstellt und gepackt wird, nicht im lokalen Repository gefunden werden kann, während ein anderes Projekt erstellt wird, das sie als Abhängigkeit hat. Wir erhalten eine Fehlermeldung wie:

Ziel für Projekt X konnte nicht ausgeführt werden: Abhängigkeiten für Projekt X konnten nicht aufgelöst werden: Fehler beim Auffinden von Y in [Archivarchiv] wurde im lokalen Repository zwischengespeichert. Die Auflösung wird erst erneut versucht, wenn das Aktualisierungsintervall von intern abgelaufen ist oder Aktualisierungen erzwungen werden. >

Dabei ist X das zu erstellende Projekt und Y das angeblich fehlende Artefakt. Wenn Sie in das lokale Repository schauen, ist das Artefakt dort. Dieses Artefakt wird niemals in unserem Archiv-Repository installiert, daher basiert das Problem ausschließlich auf dem lokalen Repository.

Wir haben verschiedene Profile in settings.xml und natürlich "mvn -U" ausprobiert. Weder nützen sie etwas, noch sollten sie es tun, weil dieses Artefakt niemals weiter als bis zum lokalen Repository geht.

Die einzigen zwei Dinge, die zu funktionieren scheinen, sind, sehr lange zu warten, bis sich der Maven verbessert hat, oder das lokale Repository vollständig zu löschen. Vermutlich hängt die Warteoption mit dem oben genannten Aktualisierungsintervall zusammen.

Wir haben dieses Problem mit Maven 3.0.2 und 3.0.3 erlebt. Wir verwenden Archiva 1.0.3 (aber auch dies sollte kein Faktor sein). Jede Hilfe wäre sehr dankbar.

Das lokale Maven-Repo verfolgt, wo Artefakte ursprünglich aus einer Datei mit dem Namen "_maven.repositories" im Artefaktverzeichnis stammen. Nach dem Entfernen funktionierte der Build. Diese Antwort hat das Problem für mich behoben.

Da die Optionen hier für mich nicht funktionierten, teile ich mit, wie ich es gelöst habe:

Mein Projekt hat ein übergeordnetes Projekt (mit einer eigenen pom.xml), das viele untergeordnete Module enthält, von denen eines (A) von einem anderen untergeordneten Modul (B) abhängig ist. Als ich es mvn packagein A versuchte , funktionierte es nicht, weil B nicht gelöst werden konnte.

Die Ausführung mvn install im übergeordneten Verzeichnis hat den Job erledigt. Danach konnte ich mvn packageinnerhalb von A tun und nur dann konnte es B finden.

Selbst im Offline-Modus überprüft maven Remote-Repositorys, wenn für die Abhängigkeit eine _remote.repositorys-Markierung vorhanden ist. Wenn Sie im Offline-Modus arbeiten müssen, müssen Sie diese Dateien möglicherweise löschen.

Der einfache Shell-Befehl unten löscht diese Markierungsdateien. Dies ist sicher, wenn Sie nur den Offline-Modus für das Gerät verwenden. Ich würde dies NICHT auf einem Computer tun, der Dateien aus dem Web abrufen muss.

Ich habe diese Strategie auf einem Build-Server verwendet, der nicht mit dem Web verbunden ist. Wir müssen das Repository dorthin übertragen, die Markierungsdateien löschen und dann im Offline-Modus ausführen.

Unter Linux / Unix können Sie die Remote-Repository-Markierungsdateien folgendermaßen löschen:

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

Als mir das passierte, hatte ich meine settings.xml blind aus einer Vorlage kopiert und sie hatte immer noch das leere <localRepository/>Element. Dies bedeutet, dass beim Auflösen von Abhängigkeiten kein lokales Repository verwendet wird (obwohl Ihre installierten Artefakte immer noch am Standardspeicherort abgelegt werden). Als ich das ersetzt hatte, <localRepository>${user.home}\.m2\repository</localRepository>fing es an zu funktionieren.

Für * nix wäre das wohl <localRepository>${user.home}/.m2/repository</localRepository>.

Maven erinnert sich, als er etwas nicht gefunden hat. Der Schlüssel lautet "Die Auflösung wird erst erneut versucht, wenn das Aktualisierungsintervall von intern abgelaufen ist oder Aktualisierungen erzwungen werden ->".

Die schnelle Lösung besteht darin, Ihr lokales "Repository" -Unterverzeichnis für das Problemartefakt zu löschen - vorausgesetzt, Sie haben das Problem damit behoben. :) :)

mvn -U wird die Aktualisierung aus dem Remote-Repository erzwingen - vorausgesetzt, Sie haben Remote jetzt mit diesem Artefakt gefüllt.

Fang alle. Wenn die hier genannten Lösungen nicht funktionieren (in meinem Fall passiert), löschen Sie einfach alle Inhalte aus dem Ordner / Verzeichnis '.m2' und tun Sie dies mvn clean install.

Wenn Sie <repositories/>in Ihrer pom.xml definiert haben , wird Ihr lokales Repository anscheinend ignoriert.

Sogar ich habe mich diesem Problem gestellt und es auf zwei Arten gelöst:

1) Wählen Sie in Ihrer IDE ein Projekt aus und bereinigen Sie alle Projekte. Installieren Sie dann alle Maven-Abhängigkeiten, indem Sie mit der rechten Maustaste auf Projekt klicken -> gehen Sie zu Maven und aktualisieren Sie Projektabhängigkeiten. Wählen Sie alle Projekte gleichzeitig aus, um sie zu installieren. Sobald dies erledigt ist, führen Sie das jeweilige Projekt aus

2) Else Was können Sie tun , ist Prüfung in der pom.xml für die Abhängigkeiten , für die Sie Fehler bekommen und „MVN saubere Installation“ diejenigen abhängigen Projekt erste und die Installation von maven Abhängigkeiten des aktuellen Projekts , in dem Sie Problem konfrontiert. Auf diese Weise werden die Abhängigkeiten des lokalen Projekts erstellt und Gläser erstellt.

Ich stoße auf ein ähnliches Problem, wenn mein neues Projekt von oracle jdbc jar abhängt (das ich in meinem lokalen Repository installiert habe und für andere Projekte gut funktioniert). Ich habe die Option -U ausprobiert, die .lastupdate-Datei oder das gesamte Verzeichnis gelöscht und erneut heruntergeladen, aber es hat nicht funktioniert. Schließlich habe ich das Verzeichnis gelöscht und es wieder lokal installiert, es funktioniert.

Einer der Fehler, den ich bei Maven gefunden habe, ist, wenn ich meine Datei settings.xml in das falsche Verzeichnis gestellt habe. Es muss sich im Ordner .m2 unter dem Home-Verzeichnis Ihres Benutzers befinden. Stellen Sie sicher, dass sich diese an der richtigen Stelle befindet (zusammen mit settings-security.xml, wenn Sie diese verwenden).

Ich hatte DependencyResolutionExceptionin Ubuntu Linux, als ich lokale Artefakte über ein Shell-Skript installiert habe. Die Lösung bestand darin, die lokalen Artefakte zu löschen und "manuell" erneut zu installieren - mvn install:install-fileüber das Terminal.

Dies geschah, weil ich httpstatt httpsin diesem hatte:

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

Ich hatte den gleichen Fehler aus einer anderen Ursache: Ich hatte ein Starter-POM erstellt, das unsere "Good Practice" -Abhängigkeiten enthielt, und es lokal erstellt und installiert, um es zu testen. Ich konnte es im Repo "sehen", aber ein Projekt, das es verwendete, bekam den obigen Fehler. Was ich getan hatte, war das Starter-POM auf Pom zu setzen, also gab es kein JAR. Maven hatte völlig Recht, dass es nicht in Nexus war - aber ich hatte nicht damit gerechnet, also war der Fehler, ähm, nicht hilfreich. Durch Ändern des Starter-POM auf normale Verpackung und erneutes Installieren wurde das Problem behoben.