Come costringo Maven a utilizzare il mio repository locale invece di andare in repository remoti per recuperare artefatti?

97

Sto usando Maven 3.3.3 con Java 8 su Mac Yosemite. Ho un progetto multimodulo.

    <modules>
            <module>first-module</module>
            <module>my-module</module>
                …
    </modules>

Quando costruisco uno dei miei moduli figlio, ad esempio "mio-modulo" dall'alto, usando "mvn clean install", la build tenta di scaricare gli artefatti del modulo figlio da un repository remoto che ho definito nel mio ~ / .m2 /settings.xml file. L'output è sotto

[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building my-module 87.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
Downloading: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml
Downloading: http://download.java.net/maven/2/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml
Downloaded: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml (788 B at 0.9 KB/sec)
Downloading: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/first-module-87.0.0-20151104.200545-4.pom

Come costringo Maven a controllare il mio repository ~ / .m2 / locale prima di provare a eseguire il download dai repository remoti? Di seguito è dove ho i miei repository remoti definiti nel mio file ~ / .m2 / settings.xml ...

<profile>
    <id>releases</id>
    <activation>
        <property>
            <name>!releases.off</name>
        </property>
    </activation>
    <repositories>
        <repository>
            <id>releases</id>
            <url>https://my.remoterepository.com/nexus/content/repositories/releases/</url>
            <releases>
                <enabled>true</enabled>
            </releases>
            <snapshots>
                <enabled>false</enabled>
            </snapshots>
        </repository>
    </repositories>
</profile>
<profile>
    <id>snapshots</id>
    <activation>
        <property>
            <name>!snapshots.off</name>
        </property>
    </activation>
    <repositories>
        <repository>
            <id>snapshots</id>
            <url>https://my.remoterepository.com/nexus/content/repositories/snapshots/</url>
            <releases>
                <enabled>false</enabled>
            </releases>
            <snapshots>
                <enabled>true</enabled>
            </snapshots>
        </repository>
    </repositories>
</profile>

Modifica: in risposta alla risposta che dice che il download si verifica quando l'artefatto non è presente, di seguito è riportato l'output del terminale in cui provo che il file era lì nel mio repository ma Maven sta cercando di scaricarlo comunque ...

Daves-MacBook-Pro-2:my-module davea$ ls -al ~/.m2/repository/org/mainco/subco/first-module/87.0.0-SNAPSHOT/first-module-87.0.0-SNAPSHOT.jar 
-rw-r--r--  1 davea  staff  10171 Nov  5 10:22 /Users/davea/.m2/repository/org/mainco/subco/first-module/87.0.0-SNAPSHOT/first-module-87.0.0-SNAPSHOT.jar
Daves-MacBook-Pro-2:my-module davea$ mvn clean install
[INFO] Scanning for projects...
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for org.mainco.subco:my-module:jar:87.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but found duplicate declaration of plugin org.apache.maven.plugins:maven-antrun-plugin @ org.mainco.subco:my-module:[unknown-version], /Users/davea/Documents/sb_workspace/my-module/pom.xml, line 678, column 12
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING] 
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building my-module 87.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
Downloading: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml
Downloading: http://download.java.net/maven/2/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml
Downloaded: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/maven-metadata.xml (788 B at 0.8 KB/sec)
Downloading: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/first-module-87.0.0-20151106.043202-8.pom
Downloaded: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/first-module/87.0.0-SNAPSHOT/first-   module-87.0.0-20151106.043202-8.pom (3 KB at 21.9 KB/sec)
Downloading: http://download.java.net/maven/2/org/mainco/subco/subco/87.0.0-SNAPSHOT/maven-metadata.xml
Downloading: https://my.remoterepository.com/nexus/content/repositories/snapshots/org/mainco/subco/subco/87.0.0-SNAPSHOT/maven-metadata.xml
maven  repository  maven-3  artifacts 
— Dave
fonte
2
Maven fa controllare il repository locale prima di tentare di scaricare un manufatto da un repository remoto. Sei sicuro che il tuo locale avesse questi artefatti prima di tentare questa build? Ora puoi ispezionare il tuo repository locale e provare comunque un'altra build. Inoltre, puoi specificare dove si trova il tuo repository locale nel settings.xml(vedi qui ).
— mystarrocks il
Sebbene non abbia specificato il mio repository nel mio file settings.xml, è l'impostazione predefinita che Maven ha configurato per me - ~ / .m2 / repository. Devo specificarlo anche quando è l'impostazione predefinita?
— Dave
Per me ci sono altri file nei miei repository locali, come * .sha1 o * .lastUpdate. eliminare altri file tranne * .jar e * .pom impedirà a Maven di scaricare nuovamente il file dal repository remoto
— Harun

Risposte:

45

La dipendenza ha una versione istantanea. Per gli snapshot, Maven controllerà il repository locale e se l'elemento trovato nel repository locale è troppo vecchio, tenterà di trovarne uno aggiornato nei repository remoti. Questo è probabilmente quello che stai vedendo.

Notare che questo comportamento è controllato dalla updatePolicydirettiva nella configurazione del repository (che è dailyper impostazione predefinita per i repository di snapshot).

— Andreas Veithen
fonte
16
È possibile "sovrascriverlo" tramite l'argomento del comando della console? Come: mvn clean install -FORCE_COMMAND
— Naxos84
21
"Troppo vecchio" cosa significa? Sceglie l'istantanea più recente che riesce a trovare, sia locale che remota? Sarebbe sicuramente un comportamento orribile. Se ho appena creato un'istantanea, voglio davvero usare quella, non quella che la build CI ha creato solo un momento dopo.
— Tom Quarendon
Si prega di spiegare di più su cosa significa "troppo vecchio"?
— Đỗ Công Bằng
32

Usa mvn --helpe puoi vedere l'elenco delle opzioni.

C'è un'opzione come -nsu,--no-snapshot-updates Suppress SNAPSHOT updates

Quindi utilizzare il comando mvn install -nsupuò forzare la compilazione con il repository locale.

— Zheng Zhongqi
fonte
10
Puoi anche usarlo -oper un comportamento "offline"
— Sean
8
L'opzione -nsu non impedisce a mvn di provare e fallire a scaricare un artefatto da remoto se non è stato ancora scaricato invece di utilizzare la build locale come quando l'artefatto è stato creato e installato localmente. -
— user1767316
Ho avuto lo stesso problema con un artefatto che non veniva ancora scaricato e questo mi ha risolto
— Luigi Cristalli
15

Per forzare davvero Maven a utilizzare solo il tuo repository locale, puoi eseguire mvn <goals> -o. La -odice Maven per farvi lavorare "offline", e rimarrà fuori dalla rete.

— Sean
fonte
5
L'opzione -o non impedisce a mvn di provare e fallire a scaricare un artefatto da remoto se non è stato ancora scaricato invece di usare la build locale come quando l'artefatto è stato creato e installato localmente.
— user1767316
2
è vero - se non hai una copia locale, sei sfortunato. Questo è utile per i progetti che hai creato in precedenza, ma potenzialmente hanno modifiche SNAPSHOT recenti che non ti interessano.
— Sean
O anche se non hai mai realizzato il progetto, potresti prepararti per la sua realizzazione offline conmvn dependency:go-offline
— Aldian
Cosa succede se hai una copia locale che hai appena installato (quindi non è mai distribuita / disponibile nel repository di snapshot remoto)?
— Vivek Chavda
1
Ah, ho appena creato un progetto pom con una raccolta di dipendenze, ma non ho specificato <type> pom </type> nel progetto in uso, quindi stava cercando un barattolo (e ovviamente non è riuscito a trovarlo, nemmeno in modalità offline)
— Vivek Chavda
4

Nel mio caso avevo un progetto multi modulo proprio come te. Ho dovuto modificare un ID di gruppo di una delle librerie esterne da cui dipendeva il mio progetto, come mostrato di seguito.

A partire dal:

<dependencyManagement>
    <dependency>
        <groupId>org.thirdparty</groupId>
        <artifactId>calculation-api</artifactId>
        <version>2.0</version>
        <type>jar</type>
        <scope>provided</scope>
    </dependency>
<dependencyManagement>

Per:

<dependencyManagement>
   <dependency>
      <groupId>org.thirdparty.module</groupId>
        <artifactId>calculation-api</artifactId>
        <version>2.0</version>
        <type>jar</type>
        <scope>provided</scope>
    </dependency>
<dependencyManagement>

Presta attenzione alla sezione <groupId>. Si è scoperto che mi stavo dimenticando di modificare la sezione corrispondente dei sottomoduli che definiscono questa dipendenza nei loro file pom.

Mi ha fatto impazzire perché il modulo era disponibile localmente.

— Willa
fonte
4

Segui i passaggi seguenti:

    1. Assicurati di eliminare tutto il contenuto della cartella jar che si trova nel tuo locale tranne il jar che desideri conservare.
      Ad esempio file come .repository, .pom, .sha1, .lastUpdated ecc.
    1. Esegui il mvn clean install -ocomando

Ciò aiuterà a utilizzare i file jar del repository locale piuttosto che connettersi a qualsiasi repository.

— Madhu
fonte
1
Solo la rimozione *.repositoriese i *.sha1file hanno funzionato per me
— DLight
2

L'opzione -o non ha funzionato per me perché l'artefatto è ancora in fase di sviluppo e non ancora caricato e maven (3.5.x) prova ancora a scaricarlo dal repository remoto perché è la prima volta, secondo l'errore che ottengo.

Tuttavia questo lo ha risolto per me: https://maven.apache.org/general.html#importing-jars

Dopo l'installazione manuale non è necessario utilizzare nemmeno l'opzione offline.

AGGIORNARE

Ho appena ricostruito la dipendenza e ho dovuto reimportarla: il normale mvn clean installnon era sufficiente per me

— Luigi Cristalli
fonte
-1

Maven controlla sempre prima il tuo repository locale, tuttavia, la tua dipendenza deve essere installata nel tuo repository affinché Maven la trovi.

Esegui mvn installprima il modulo delle dipendenze, quindi crea il modulo dipendente.

— Oliver
fonte
1
Ho modificato la mia domanda per mostrare che l'artefatto è nel repository (nota il comando "ls -al" che eseguo. Tuttavia Maven sta tentando di scaricarlo comunque. Altre idee?
— Dave
5
@Oliver: ti manca il fatto che per gli artefatti nel repository locale, Maven potrebbe comunque consultare i repository remoti se l'artefatto è un'istantanea troppo vecchia.
— Andreas Veithen
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.