2011-10-21 18 views
6

quando sto facendo lo sviluppo ho spesso bisogno di cambiare una dipendenza, ma non sono pronto a distribuire le mie modifiche. Ad esempio, sto lavorando al progetto Foo e mi rendo conto che devo aggiungere un metodo alla libreria comune. Prima di distribuire questa modifica nel nostro repository interno, vorrei installare le modifiche alla libreria comune (mvn install) e ricompilare Foo per utilizzare la libreria comune nel repository locale (nota che sto utilizzando tutte le versioni di SNAPSHOT).Perché Maven usa il mio repository interno prima del mio repository locale?

Tuttavia, dopo I mvn install la mia libreria comune, quando ricompongo Foo non utilizza la nuova libreria comune - continua a utilizzare l'ultimo SNAPSHOT della libreria comune nel repository interno. Se distribuisco la libreria comune modificata, Foo lo preleva immediatamente.

Come posso convincere Maven a cercare prima nel repository locale?

UPDATE: quando il file viene installato nel repository locale, ottiene un nome come foo-1.0.0-SNAPSHOT.jar, ma quando lo distribuisco, ottiene un timestamp foo-1.0.0-20111104.191316-23.jar. Penso che questo sia il motivo per cui l'artefatto remoto viene tirato ogni volta. Qualche idea sul perché mvn install non funziona come mvn deploy? Ha a che fare con il fatto che ho un repository di istantanee impostato per la distribuzione?

+0

Avete un 'localRepository' nella vostra [settings.xml] (http://maven.apache.org/settings.html) che punta a una posizione inesistente? – millhouse

+0

Confronta la data di sistema con la data del sistema di repo interno (ad es. Nexus). Se è molto più avanti, i suoi timestamp "vinceranno" – millhouse

risposta

3

Per impostazione predefinita, Maven verifica la presenza di nuove versioni di risorse SNAPSHOT una volta al giorno. Quando esegue questo controllo, scaricherà SNAPSHOT da repository remoti che sono più recenti di quello che hai localmente. O i tuoi timestamp degli artefatti sono fuori sincrono e stai facendo qualcosa per ignorare la politica di aggiornamento di Maven (come calling it with -U o setting the udpatePolicy a "sempre"), altrimenti il ​​repository locale su cui stai installando l'artefatto non è lo stesso di te " in seguito a correre contro Maven. Quello che stai descrivendo non è il tipico comportamento di Maven. Per una risposta migliore, fornisci maggiori dettagli nella tua domanda.

Un indicatore che si può cercare: dopo aver installato il tuo artefatto comune, quando compili successivamente Foo, Maven scarica di nuovo l'artefatto comune? Se è così, allora lo sta davvero ricevendo dal telecomando, e devi controllare le impostazioni di aggiornamento. Altrimenti, hai qualcosa di strano in corso a livello locale.

+0

Grazie Ryan, chiaramente nessuno sarà in grado di dirmi esattamente cosa sta succedendo senza ulteriori dettagli. È utile sapere che questo non è un comportamento standard in primo luogo, quindi posso approfondire ulteriormente! – schmmd

+0

Ho aggiunto qualche altro dettaglio - vedi il mio AGGIORNAMENTO alla fine della mia domanda. – schmmd

+0

Per un po 'di tempo, Maven ha utilizzato i timestamp per identificare in modo univoco le versioni di istantanee distribuite su un repository remoto e "SNAPSHOT" è semplicemente un alias per il più recente di questi artefatti con data e ora. Penso che sia stato da qualche parte intorno alla 2.1.0 che è iniziato? Non cambia nulla riguardo al tuo problema. –

0

Puoi provare questa opzione. Questo ha funzionato per me.

Nella principale pom.xml del progetto, l'impostazione di "istantanee" è stata modificata in "falso".

<repository> 
    <id>yourRepo</id> 
    <name>Repository</name> 
    <url>http://your.repo.com/repo</url> 
    <snapshots> 
     <enabled>false</enabled> 
    </snapshots> 
</repository> 
Problemi correlati