Maven nie znajduje lokalnego artefaktu


108

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.


1
Czy Maven rejestruje coś w trakcie lub tuż przed „czekaniem”? To znaczy, czy próbuje połączyć się z nieosiągalnym repozytorium? Ponadto, czy problematyczne artefakty są „-SNAPSHOT”?
noahlz

Maven nie rejestruje niczego poza błędem, o którym wspomniałem powyżej. I tak, to jest zależność od migawki.
user1686620


1
Czy zainstalowałeś pakiet kompilacji przed próbą zbudowania drugiego projektu?
khmarbaise

3
Podoba mi się, że komunikat o błędzie jest zdaniem run-on, a nie poprawnym gramatycznie. W ten sposób nie wiemy na pewno, czy nie może znaleźć Y, czy Y został zapisany lokalnie w pamięci podręcznej, czy też jedno i drugie. Zresztą mam podobny problem. Udało mi się to rozwiązać za pomocą opcji -U, ponieważ moje zależności znajdują się w wewnętrznym repozytorium mojej firmy. Dlaczego artefakty, których potrzebujesz, nie są wdrażane w wewnętrznym repozytorium Twojej firmy?
jyoungdev,

Odpowiedzi:


81

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.


26
Dla mnie był to plik o nazwie „_remote.repositories”. Usunąłem go i zadziałało! Dziękuję za sztuczki!
perbellinio

2
Dzięki temu plik o nazwie _remote.repositories również był obecny. zdarzyło mi się to, gdy nasz nexus przestał mieć połączenie sieciowe, więc nie może uzyskać zależności
cabaji99

1
Dostarczone rozwiązanie działa. Interesuje mnie jednak, dlaczego w ogóle ten problem występuje. Czy ktoś mógłby mi szybko wyjaśnić? Czy muszę zrobić coś inaczej?
Janothan

Jeśli chcesz raz ominąć to sprawdzanie pochodzenia (bez usuwania metaplików), spróbuj przejść aether.enhancedLocalRepository.trackingFilename=some_dummy_file_namedo procesu rozwiązywania zależności; Najłatwiejszym sposobem jest dodanie właściwości systemowej -D do polecenia wywołania.
Janaka Bandara

@Janothan IMO link w odpowiedzi dostarcza całkiem dobrego wyjaśnienia :)
Janaka Bandara

40

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.


3
DZIĘKUJĘ CI! to doprowadzało mnie do szału. mvn clean package jboss-as: deploy działało, kiedy wykonywałem je w jednej linii, ale nie, gdy robiłem je oddzielnie.
PMorganCA

19

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

1
To rozwiązanie zadziałało dla mnie, dla zależności, którą skopiowałem z innego komputera, który nie jest dostępny w centralnym repozytorium. W poleceniu brakuje jednak kilku znaków. Oto pełne polecenie: znajdź. -name "_remote.repositories" -type -f -delete
Hans Deragon,

2
Lub, zamiast usuwać, powinieneś być w stanie „zmylić” Mavena, aby nie patrzył na _remote.repositoriesplik, przechodząc -Daether.enhancedLocalRepository.trackingFilename=some_dummy_file_namedo procesu. (Nie próbowałem na rzeczywistej kompilacji Mavena, ale działa przy wywoływaniu Mavena programowo; więc ten pierwszy powinien również działać)
Janaka Bandara

1
Dokonałem tego znalezienia i usunięcia określonych zależności (słoików), których Maven nie znalazł, ponieważ zostały one wymienione i możliwe do zarządzania w (<10). Było to spowodowane błędną konfiguracją wskazującą na zdalny Nexus, który nie jest obecnie dostępny (jak rozumiem ...). Nie ma więc rzeczywistej potrzeby zamiatania wszystkich repozytoriów w celu usunięcia. W każdym razie to rozwiązanie uratowało sytuację. To działa dla mnie.
Diego 1974

9

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 .


6
$ {user.home} \. m2 \ repozytorium jest domyślnym repozytorium, więc usunięcie pustego tagu powinno działać podobnie.
Luis Muñoz

9

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.


2

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.



1

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.


0

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.


0

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


0

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.


0

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>

0

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


-1

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.


Ta odpowiedź prawdopodobnie byłaby lepsza jako komentarz, ponieważ nie jest to bezpośrednia odpowiedź na pytanie.
00prometeusz
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.