Maven nie znajduje lokalnego artefaktu

Czasami maven narzeka, że ​​określonej zależności, która jest budowana i pakowana lokalnie, nie można znaleźć w lokalnym repozytorium podczas budowania innego projektu, który ma ją jako zależność. Otrzymujemy błąd taki jak:

Nie udało się zrealizować celu w projekcie X: Nie można rozwiązać zależności dla projektu X: Błąd znalezienia Y w [repozytorium archiwów] został zapisany w pamięci podręcznej w lokalnym repozytorium, rozwiązanie nie zostanie ponownie podjęte, dopóki nie upłynie interwał aktualizacji wewnętrznej lub nie zostaną wymuszone aktualizacje - >

Gdzie X to budowany projekt, a Y to rzekomo brakujący artefakt. Jeśli zajrzysz do lokalnego repozytorium, artefakt tam jest. Ten artefakt nigdy nie jest instalowany w naszym repozytorium archiwów, więc problem dotyczy wyłącznie repozytorium lokalnego.

Wypróbowaliśmy różne profile w settings.xml i oczywiście „mvn -U”. Ani nie robią nic dobrego, ani nie powinny, ponieważ ten artefakt nigdy nie wykracza poza lokalne repozytorium.

Jedyne dwie rzeczy, które wydają się działać, to bardzo długie czekanie, aż program Maven się poprawi, lub całkowite usunięcie lokalnego repozytorium. Przypuszczalnie opcja oczekiwania jest związana z wyżej wymienionym interwałem aktualizacji.

Ten problem wystąpił w przypadku maven 3.0.2 i 3.0.3. Używamy Archiva 1.0.3 (ale znowu nie powinno to mieć znaczenia). Każda pomoc byłaby bardzo mile widziana.

Lokalne repozytorium Maven śledzi, skąd pochodziły artefakty, używając pliku o nazwie „_maven.repositories” w katalogu artefaktów. Po usunięciu kompilacja działała. Ta odpowiedź rozwiązała problem.

Ponieważ opcje tutaj nie działają dla mnie, udostępniam, jak to rozwiązałem:

Mój projekt ma projekt nadrzędny (z własnym pom.xml), który ma wiele modułów potomnych, z których jeden (A) jest zależny od innego podrzędnego (B). Kiedy próbowałem mvn packagew A, nie zadziałało, ponieważ B nie można było rozwiązać.

Wykonanie mvn install w katalogu nadrzędnym wykonało zadanie. Potem mogłem zrobić mvn packagewewnątrz A i dopiero wtedy mógł znaleźć B.

Nawet w trybie offline, maven sprawdzi zdalne repozytoria, czy istnieje znacznik _remote.repositories dla zależności. Jeśli chcesz działać w trybie offline, może być konieczne usunięcie tych plików.

Poniższe proste polecenie powłoki usuwa te pliki znaczników. Jest to bezpieczne, jeśli używasz tylko trybu offline na urządzeniu. NIE zrobiłbym tego na komputerze, który musi pobierać pliki z sieci.

Użyłem tej strategii na serwerze kompilacji, który jest odłączony od sieci. Musimy przenieść do niego repozytorium, usunąć pliki znaczników, a następnie uruchomić w trybie offline.

W systemie Linux / Unix możesz usunąć pliki znaczników zdalnego repozytorium w następujący sposób:

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

Kiedy mi się to przydarzyło, było to spowodowane tym, że ślepo skopiowałem plik settings.xml z szablonu i nadal zawierał on pusty <localRepository/>element. Oznacza to, że nie ma lokalnego repozytorium używanego podczas rozwiązywania zależności (chociaż zainstalowane artefakty nadal są umieszczane w domyślnej lokalizacji). Kiedy to zastąpiłem, <localRepository>${user.home}\.m2\repository</localRepository>zaczęło działać.

<localRepository>${user.home}/.m2/repository</localRepository>Przypuszczam , że tak będzie dla * nix .

Maven pamięta, kiedy czegoś nie znalazł. Kluczem jest „rozwiązanie nie zostanie podjęta ponownie, dopóki nie upłynie interwał aktualizacji wewnętrznej lub nie zostaną wymuszone aktualizacje ->”

Szybkim rozwiązaniem jest usunięcie lokalnego podkatalogu „repozytorium” dla artefaktu powodującego problem - zakładając, że problem został rozwiązany. :)

mvn -U wymusi aktualizację ze zdalnego repozytorium - ponownie, zakładając, że zapełniłeś teraz zdalne wspomniane artefakt.

Złap wszystkie. Jeśli wymienione tutaj rozwiązania nie działają (tak się stało w moim przypadku), po prostu usuń całą zawartość z folderu / katalogu '.m2' i zrób mvn clean install.

Jeśli <repositories/>zdefiniowałeś w swoim pom.xml, Twoje lokalne repozytorium jest ignorowane.

Nawet ja stanąłem przed tym problemem i rozwiązałem go na dwa sposoby:

1) W swoim IDE wybierz projekt i wyczyść wszystkie projekty, a następnie zainstaluj wszystkie zależności maven, klikając prawym przyciskiem myszy projekt -> przejdź do maven i Aktualizuj zależności projektu, wybierz wszystkie projekty naraz, aby zainstalować to samo. Gdy to zrobisz, uruchom konkretny projekt

2) W przeciwnym razie To, co możesz zrobić, to sprawdzić w pom.xml zależności, dla których otrzymujesz błąd i „mvn clean install” najpierw te zależne projekty i zależności install maven bieżącego projektu, w którym występuje problem. W ten sposób zostaną zbudowane zależności lokalnego projektu i utworzone słoiki.

Występuję z podobnym problemem, gdy mój nowy projekt jest zależny od jdbc jar oracle (który zainstalowałem w moim lokalnym repozytorium i działa dobrze w innych projektach). Wypróbowałem opcję -U, usuwając plik .lastupdate lub cały katalog i ponownie ściągnij, ale to nie zadziałało. w końcu usunąłem katalog i zainstalowałem go ponownie lokalnie, działa.

Jednym z błędów, które znalazłem w Maven, jest umieszczenie pliku settings.xml w niewłaściwym katalogu. Musi znajdować się w folderze .m2 w katalogu domowym użytkownika. Upewnij się, że znajduje się we właściwym miejscu (wraz z plikiem settings-security.xml, jeśli go używasz).

Miałem DependencyResolutionExceptionw Ubuntu Linux, kiedy zainstalowałem lokalne artefakty za pomocą skryptu powłoki. Rozwiązaniem było usunięcie lokalnych artefaktów i zainstalowanie ich ponownie „ręcznie” - dzwoniąc mvn install:install-fileprzez terminal.

Stało się tak, ponieważ httpzamiast tego miałem https:

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

sprawdź, czy twój artefakt Y ma opakowanie ustawione na "jar". Jeśli zdefiniowałeś to jako „wojnę” przez błąd lub kopiuj wklej, pokaże to dziwne „zostało zapisane w pamięci podręcznej w lokalnym repozytorium, rozwiązanie nie zostanie ponowione, dopóki nie upłynie interwał aktualizacji wewnętrznej lub aktualizacje zostaną wymuszone”. Spodziewałbym się czegoś w stylu „artefakt Y to wojna, oczekiwany rodzaj słoika”.

Miałem ten sam błąd z innej przyczyny: utworzyłem startowy POM zawierający nasze zależności „dobrych praktyk”, a następnie zbudowałem i zainstalowałem go lokalnie, aby go przetestować. Mogłem „zobaczyć” to w repozytorium, ale projekt, który go używał, otrzymał powyższy błąd. To co zrobiłem, to nastawiłem startowy POM na pom, więc nie było JAR-a. Maven miał rację, że nie było go w Nexusie - ale nie spodziewałem się, że tak będzie, więc błąd był, hmm, nieprzydatny. Zmiana startowego POM na normalne opakowanie i ponowna instalacja rozwiązały problem.