Maven non riesce a trovare artefatto locale

Di tanto in tanto Maven si lamenta del fatto che una particolare dipendenza, che è costruita e impacchettata localmente, non può essere trovata nel repository locale durante la costruzione di un altro progetto che la ha come dipendenza. Otteniamo un errore del tipo:

Impossibile eseguire l'obiettivo sul progetto X: Impossibile risolvere le dipendenze per il progetto X: Impossibile trovare Y in [repository archiva] memorizzato nella cache nel repository locale, la risoluzione non verrà ritentata fino a quando l'intervallo di aggiornamento dell'interno non sarà trascorso o gli aggiornamenti non saranno forzati - >

Dove X è il progetto in costruzione e Y è il presunto artefatto mancante. Se guardi nel repository locale, l'artefatto è lì. Questo artefatto non viene mai installato nel nostro repository di archiviazione, quindi il problema si basa esclusivamente sul repository locale.

Abbiamo provato vari profili in settings.xml e ovviamente "mvn -U". Né fare nulla di buono, né dovrebbero perché questo artefatto non va mai oltre il deposito locale.

Le uniche due cose che sembrano funzionare sono aspettare molto tempo prima che Maven si riprenda, o eliminare completamente il repository locale. Presumibilmente l'opzione di attesa è relativa al suddetto intervallo di aggiornamento.

Abbiamo riscontrato questo problema con Maven 3.0.2 e 3.0.3. Stiamo usando Archiva 1.0.3 (ma ancora una volta questo non dovrebbe essere un fattore). Qualsiasi aiuto sarebbe molto apprezzato.

Il repository Maven locale tiene traccia della provenienza degli artefatti dall'utilizzo di un file denominato "_maven.repository" nella directory degli artefatti. Dopo averlo rimosso, la build ha funzionato. Questa risposta ha risolto il problema per me.

Poiché le opzioni qui non hanno funzionato per me, condivido come l'ho risolto:

Il mio progetto ha un progetto padre (con il proprio pom.xml) che ha molti moduli figli, uno dei quali (A) ha una dipendenza da un altro figlio (B). Quando ho provato mvn packagein A, non ha funzionato perché B non poteva essere risolto.

L'esecuzione mvn install nella directory principale ha fatto il lavoro. Dopodiché, potrei fare mvn packageall'interno di A e solo allora potrebbe trovare B.

Anche in modalità offline, maven controllerà i repository remoti se è presente un indicatore _remote.repository per la dipendenza. Se è necessario operare in modalità offline, potrebbe essere necessario eliminare questi file.

Il semplice comando della shell di seguito elimina questi file marker. Questo è sicuro se utilizzi solo la modalità offline per la macchina. NON lo farei su una macchina che ha bisogno di estrarre file dal web.

Ho utilizzato questa strategia su un server di compilazione disconnesso dal web. Dobbiamo trasferire il repository su di esso, eliminare i file marker e quindi eseguire in modalità offline.

Su Linux / Unix puoi eliminare i file marker del repository remoto in questo modo:

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

Quando è successo a me, è stato perché avevo copiato ciecamente il mio settings.xml da un modello e aveva ancora l' <localRepository/>elemento vuoto . Ciò significa che non è presente alcun repository locale utilizzato per la risoluzione delle dipendenze (sebbene gli artefatti installati vengano comunque inseriti nella posizione predefinita). Quando l'ho sostituito con <localRepository>${user.home}\.m2\repository</localRepository>esso ha iniziato a funzionare.

Per * nix, sarebbe <localRepository>${user.home}/.m2/repository</localRepository>, suppongo.

Maven ricorda quando non ha trovato qualcosa. La chiave è "la risoluzione non verrà ritentata fino a quando l'intervallo di aggiornamento dell'interno non è trascorso o gli aggiornamenti non vengono forzati ->"

La soluzione rapida è eliminare la sottodirectory "repository" locale per l'artefatto del problema, supponendo che tu abbia risolto il problema con esso. :)

mvn -U forzerà l'aggiornamento dal repository remoto, di nuovo, supponendo che tu abbia popolato il remoto con detto artefatto.

Cattura tutto. Quando le soluzioni menzionate qui non funzionano (è successo nel mio caso), elimina semplicemente tutti i contenuti dalla cartella / directory ".m2" e fallo mvn clean install.

Se hai <repositories/>definito nel tuo pom.xml apparentemente il tuo repository locale viene ignorato.

Anche io ho affrontato questo problema e l'ho risolto in 2 modi:

1) Nel tuo IDE seleziona il progetto e pulisci tutti i progetti, quindi installa tutte le dipendenze di Maven facendo clic con il pulsante destro del mouse su progetto -> vai a Maven e Aggiorna le dipendenze del progetto seleziona tutti i progetti contemporaneamente per installare lo stesso. Fatto ciò, esegui il progetto specifico

2) Altrimenti, che si può fare è il check-nella pom.xml per le dipendenze per i quali si stanno ottenendo l'errore e "mvn clean install" coloro dipendente primo progetto e le dipendenze installa Maven del progetto attuale in cui di fronte a voi problema. In questo modo verranno create le dipendenze del progetto locale e verranno creati i jar.

Corro al problema simile quando il mio nuovo progetto dipende da Oracle jdbc jar (che ho installato nel mio repository locale e funziona bene per altri progetti). Ho provato l'opzione -U, eliminando il file .lastupdate o l'intera directory e scaricando di nuovo, ma non ha funzionato. infine, ho cancellato la directory e l'ho installato di nuovo in locale, funziona.

Uno degli errori che ho riscontrato in Maven è quando ho inserito il mio file settings.xml nella directory sbagliata. Deve essere nella cartella .m2 nella directory home dell'utente. Controlla per assicurarti che sia nel posto giusto (insieme a settings-security.xml se lo stai usando).

Avevo DependencyResolutionExceptionin Ubuntu Linux quando ho installato artefatti locali tramite uno script di shell. La soluzione era eliminare gli artefatti locali e installarli di nuovo "manualmente", chiamando mvn install:install-filetramite terminale.

Questo è successo perché al httpposto di httpsquesto avevo :

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

controlla se il tuo artefatto Y ha il packaging impostato su "jar". Se è stato definito come "war" per errore o copia incolla, verrà visualizzato questo strano "è stato memorizzato nella cache nel repository locale, la risoluzione non verrà ritentata fino a quando l'intervallo di aggiornamento interno non sarà trascorso o gli aggiornamenti non saranno forzati". Mi aspetterei qualcosa del tipo "artefatto Y è guerra, atteso tipo di vaso".

Ho avuto lo stesso errore per una causa diversa: avevo creato un POM iniziale contenente le nostre dipendenze di "buona pratica" e l'ho costruito e installato localmente per testarlo. Potrei "vederlo" nel repo, ma un progetto che lo ha utilizzato ha ottenuto l'errore di cui sopra. Quello che avevo fatto era impostare il POM iniziale su pom, quindi non c'era JAR. Maven aveva ragione sul fatto che non fosse in Nexus, ma non mi aspettavo che lo fosse, quindi l'errore è stato, ummm, inutile. La modifica del POM di avviamento nella confezione normale e la reinstallazione hanno risolto il problema.