Wie zwinge ich Maven, mein lokales Repository zu verwenden, anstatt zu Remote-Repos zu gehen, um Artefakte abzurufen?

96

Ich verwende Maven 3.3.3 mit Java 8 auf Mac Yosemite. Ich habe ein Multi-Modul-Projekt.

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

Wenn ich eines meiner untergeordneten Module, z. B. "my-module" von oben, mit "mvn clean install" erstelle, versucht der Build, die Artefakte des untergeordneten Moduls aus einem Remote-Repository herunterzuladen, das ich in meinem ~ / .m2 definiert habe Datei /settings.xml. Die Ausgabe ist unten

[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

Wie zwinge ich Maven, zuerst mein lokales ~ / .m2 / Repository zu überprüfen, bevor ich versuche, es von den Remote-Repositorys herunterzuladen? Unten habe ich meine Remote-Repositorys in meiner Datei ~ / .m2 / settings.xml definiert.

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

Bearbeiten: Als Antwort auf die Antwort, dass der Download erfolgt, wenn das Artefakt nicht vorhanden ist, sehen Sie unten die Terminalausgabe, in der ich beweise, dass die Datei in meinem Repo vorhanden war, aber Maven versucht, sie trotzdem herunterzuladen ...

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

— Dave
quelle

2

Maven tut Ihr lokales Repository überprüfen , bevor Sie versuchen , ein Artefakt von einem Remote - Repository zum Download bereit . Sind Sie sicher, dass Ihr Einheimischer diese Artefakte hatte, bevor Sie diesen Build versuchten? Sie können jetzt Ihr lokales Repository überprüfen und trotzdem einen anderen Build versuchen. Sie können auch angeben, wo sich Ihr lokales Repository im befindet settings.xml(siehe hier ).

— Mystarrocks

Obwohl ich mein Repository nicht in meiner Datei settings.xml angegeben habe, ist es die Standardeinstellung, die Maven für mich eingerichtet hat - ~ / .m2 / repository. Muss ich es auch dann angeben, wenn es die Standardeinstellung ist?

— Dave

Für mich befinden sich andere Dateien in meinen lokalen Repositorys, z. B. * .sha1 oder * .lastUpdate. Löschen Sie andere Dateien außer * .jar und * .pom, um zu verhindern, dass Maven die Datei erneut aus dem Remote-Repository herunterlädt

— Harun

45

Die Abhängigkeit hat eine Snapshot-Version. Für Snapshots überprüft Maven das lokale Repository. Wenn das im lokalen Repository gefundene Artefakt zu alt ist, versucht es, ein aktualisiertes in den Remote-Repositorys zu finden. Das sehen Sie wahrscheinlich.

Beachten Sie, dass dieses Verhalten von der updatePolicyDirektive in der Repository-Konfiguration gesteuert wird ( dailystandardmäßig für Snapshot-Repositorys).

— Andreas Veithen
quelle

16

Ist es möglich, dies durch ein Konsolenbefehlsargument zu "überschreiben"? Gefällt mir: mvn clean install -FORCE_COMMAND

— Naxos84

21

"Zu alt" bedeutet was? Es wählt den neuesten Schnappschuss aus, den es finden kann, ob lokal oder remote? Das wäre sicherlich ein schreckliches Verhalten. Wenn ich gerade einen Snapshot erstellt habe, möchte ich diesen wirklich verwenden, nicht den, den der CI-Build nur einen Moment später erstellt hat.

— Tom Quarendon

Bitte erläutern Sie mehr darüber, was "zu alt" bedeutet.

— ô Công Bằng

32

Verwenden mvn --help Sie und Sie können die Optionsliste sehen.

Es gibt eine Option wie -nsu,--no-snapshot-updates Suppress SNAPSHOT updates

Der Befehl use mvn install -nsukann also die Kompilierung mit dem lokalen Repository erzwingen.

— Zheng Zhongqi
quelle

10

Sie können auch -ofür "offline" Maven Verhalten verwenden

— Sean

8

Die Option -nsu verhindert nicht, dass mvn versucht, ein Artefakt remote herunterzuladen, wenn es noch nicht heruntergeladen wurde, anstatt den lokalen Build zu verwenden, wie bei der Erstellung und Installation des Artefakts vor Ort. -

— user1767316

Ich hatte das gleiche Problem mit einem Artefakt, das noch nicht heruntergeladen wurde, und dies hat es für mich behoben

— Luigi Cristalli

14

Um Maven wirklich zu zwingen , nur Ihr lokales Repo zu verwenden, können Sie mit laufen mvn <goals> -o. Der -osagt maven, dass Sie "offline" arbeiten sollen, und es bleibt außerhalb des Netzwerks.

— Sean
quelle

5

Die Option -o verhindert nicht, dass mvn versucht, ein Artefakt aus der Ferne herunterzuladen, wenn es noch nicht heruntergeladen wurde, anstatt den lokalen Build zu verwenden, wie wenn das Artefakt lokal erstellt und installiert wurde.

— user1767316

2

Das stimmt - wenn Sie keine lokale Kopie haben, haben Sie kein Glück. Dies ist nützlich für Projekte, die Sie zuvor erstellt haben, aber möglicherweise kürzlich vorgenommene SNAPSHOT-Änderungen vorgenommen haben, die Sie nicht interessieren.

— Sean

Oder selbst wenn Sie das Projekt nie erstellt haben, können Sie sich darauf vorbereiten, dass es offline erstellt wird mitmvn dependency:go-offline

— Aldian

Was ist, wenn Sie eine lokale Kopie haben, die Sie gerade installiert haben (sodass sie im Remote-Snapshot-Repo nie bereitgestellt / verfügbar ist)?

— Vivek Chavda

1

Ah, ich habe gerade ein POM-Projekt mit einer Sammlung von Abhängigkeiten erstellt, aber im konsumierenden Projekt nicht <type> pom </ type> angegeben, also nach einem Glas gesucht (und es natürlich nicht einmal gefunden) im Offline-Modus)

— Vivek Chavda

4

In meinem Fall hatte ich ein Multi-Modul-Projekt wie Sie. Ich musste eine Gruppen-ID einer der externen Bibliotheken ändern, von denen mein Projekt abhängig war (siehe unten).

Von:

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

Zu:

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

Beachten Sie den Abschnitt <groupId>. Es stellte sich heraus, dass ich vergessen hatte, den entsprechenden Abschnitt der Submodule, die diese Abhängigkeit definieren, in ihren POM-Dateien zu ändern.

Es hat mich sehr verrückt gemacht, weil das Modul lokal verfügbar war.

— Willa
quelle

4

Befolgen Sie die folgenden Schritte:

1. Stellen Sie sicher, dass Sie den gesamten Inhalt des JAR-Ordners in Ihrem lokalen Ordner löschen, mit Ausnahme des JARs, den Sie behalten möchten.
  Zum Beispiel Dateien wie .repositories, .pom, .sha1, .lastUpdated usw.
1. mvn clean install -oBefehl ausführen

Dies hilft dabei, lokale Repository-JAR-Dateien zu verwenden, anstatt eine Verbindung zu einem Repository herzustellen.

— Madhu
quelle

1

Nur entfernen *.repositoriesund *.sha1Dateien funktionierten für mich

— DLight

2

Die Option -o hat bei mir nicht funktioniert, da sich das Artefakt noch in der Entwicklung befindet und noch nicht hochgeladen wurde und maven (3.5.x) weiterhin versucht, es aus dem Remote-Repository herunterzuladen, da es laut dem Fehler, den ich erhalte, das erste Mal ist.

Dies hat es jedoch für mich behoben: https://maven.apache.org/general.html#importing-jars

Nach dieser manuellen Installation muss auch die Offline-Option nicht mehr verwendet werden.

AKTUALISIEREN

Ich habe gerade die Abhängigkeit neu erstellt und musste sie erneut importieren: Die reguläre Abhängigkeit mvn clean installwar für mich nicht ausreichend

— Luigi Cristalli
quelle

-1

Maven überprüft immer zuerst Ihr lokales Repository. Ihre Abhängigkeit muss jedoch in Ihrem Repo installiert sein, damit Maven sie findet.

Führen mvn installSie zuerst Ihr Abhängigkeitsmodul aus und erstellen Sie dann Ihr abhängiges Modul.

— Oliver
quelle

1

Ich habe meine Frage bearbeitet, um zu zeigen, dass sich das Artefakt im Repo befindet (beachten Sie den Befehl "ls -al", den ich ausführe. Dennoch versucht Maven, es trotzdem herunterzuladen. Irgendwelche anderen Ideen?

— Dave

5

@Oliver: Ihnen fehlt die Tatsache, dass Maven für Artefakte im lokalen Repository möglicherweise weiterhin die Remote-Repositorys konsultiert, wenn es sich bei dem Artefakt um einen zu alten Schnappschuss handelt.

— Andreas Veithen