Jak zmusić Mavena do używania mojego lokalnego repozytorium zamiast wychodzenia do zdalnego repozytorium w celu pobrania artefaktów?

102

Używam Maven 3.3.3 z Javą 8 na Mac Yosemite. Mam projekt wielomodułowy.

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

Kiedy buduję jeden z moich modułów podrzędnych, na przykład „mój-moduł” z góry, używając „czystej instalacji mvn”, kompilacja próbuje pobrać artefakty modułu podrzędnego ze zdalnego repozytorium, które zdefiniowałem w moim ~ / .m2 Plik /settings.xml. Wyjście jest poniżej

[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

Jak zmusić Mavena do sprawdzenia mojego lokalnego ~ / .m2 / repozytorium przed próbą pobrania ze zdalnych repozytoriów? Poniżej znajduje się miejsce, w którym mam zdefiniowane zdalne repozytoria w pliku ~ / .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>

Edycja: W odpowiedzi na odpowiedź mówiącą, że pobieranie następuje, gdy nie ma artefaktu, poniżej znajduje się wyjście terminala, w którym udowadniam, że plik był w moim repozytorium, ale Maven i tak próbuje go pobrać ...

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
źródło
2
Maven robi sprawdzić lokalne repozytorium przed próbując ściągnąć artefakt ze zdalnego repozytorium. Czy jesteś pewien, że twój lokalny miał te artefakty, zanim spróbowałeś tej kompilacji? Możesz teraz sprawdzić swoje lokalne repozytorium i mimo wszystko spróbować jeszcze raz. Możesz także określić, gdzie znajduje się twoje lokalne repozytorium settings.xml(patrz tutaj ).
— mystarrocks
Chociaż nie określiłem repozytorium w moim pliku settings.xml, jest to ustawienie domyślne, które Maven skonfigurował dla mnie - ~ / .m2 / repository. Czy muszę to określać, nawet jeśli jest to ustawienie domyślne?
— Dave
Dla mnie są inne pliki w moich lokalnych repozytoriach, takie jak * .sha1 lub * .lastUpdate. usuń inne pliki z wyjątkiem * .jar i * .pom uniemożliwi mavenowi ponowne pobranie pliku ze zdalnego repozytorium
— Harun

Odpowiedzi:

47

Zależność ma wersję migawki. W przypadku migawek Maven sprawdzi lokalne repozytorium i jeśli artefakt znaleziony w lokalnym repozytorium jest zbyt stary, spróbuje znaleźć zaktualizowany w zdalnych repozytoriach. To prawdopodobnie to, co widzisz.

Zauważ, że to zachowanie jest kontrolowane przez updatePolicydyrektywę w konfiguracji repozytorium (która jest dailydomyślnie dla repozytoriów migawek).

— Andreas Veithen
źródło
16
Czy jest możliwe „nadpisanie” tego argumentem polecenia konsoli? Na przykład: mvn clean install -FORCE_COMMAND
— Naxos84
21
Co to znaczy „za stary”? Wybiera najnowszą migawkę, jaką może znaleźć, niezależnie od tego, czy jest to lokalna, czy zdalna? To z pewnością byłoby okropne zachowanie. Jeśli właśnie utworzyłem migawkę, naprawdę chcę użyć tego, a nie tego, który zbudowała kompilacja CI chwilę później.
— Tom Quarendon,
Proszę wyjaśnić, co oznacza „za stary”?
— Đỗ Công Bằng
34

Użyj, mvn --helpa zobaczysz listę opcji.

Jest taka opcja -nsu,--no-snapshot-updates Suppress SNAPSHOT updates

Więc użyj polecenia mvn install -nsumoże wymusić kompilację z lokalnym repozytorium.

— Zheng Zhongqi
źródło
10
Możesz również użyć -odo zachowania „offline” maven
— Sean
8
Opcja -nsu nie uniemożliwia mvn próby zdalnego pobrania artefaktu, jeśli nie został on jeszcze pobrany, zamiast używania kompilacji lokalnej, tak jak wtedy, gdy artefakt został zbudowany i zainstalowany lokalnie. -
— user1767316
Miałem ten sam problem z artefaktem, który nie był jeszcze pobierany i to rozwiązało go dla mnie: maven.apache.org/general.html#importing-jars
— Luigi Cristalli
17

Aby naprawdę zmusić mavena do korzystania tylko z lokalnego repozytorium, możesz uruchomić mvn <goals> -o. -oMówi Maven pozwolić pracować „offline”, a pozostanie ono wyłączone z sieci.

— Sean
źródło
5
Opcja -o nie uniemożliwia mvn podjęcia próby zdalnego pobrania artefaktu, jeśli nie został on jeszcze pobrany, zamiast używania kompilacji lokalnej, tak jak wtedy, gdy artefakt został zbudowany i zainstalowany lokalnie.
— user1767316
2
to prawda - jeśli nie masz lokalnej kopii, nie masz szczęścia. Jest to przydatne w przypadku projektów, które zbudowałeś wcześniej, ale potencjalnie możesz mieć ostatnie zmiany SNAPSHOT, które Cię nie interesują.
— Sean
Lub nawet jeśli nigdy nie zbudowałeś projektu, możesz przygotować się do zbudowania go w trybie offlinemvn dependency:go-offline
— Aldian
Co się stanie, jeśli masz właśnie zainstalowaną kopię lokalną (więc nie jest ona nigdy wdrażana / dostępna w repozytorium zdalnych migawek)?
— Vivek Chavda
1
Ach, właśnie stworzyłem projekt pom ze zbiorem zależności, ale nie określiłem <type> pom </type> w projekcie, który jest używany, więc szukałem słoika (i oczywiście nie mogłem go znaleźć, nawet w trybie offline)
— Vivek Chavda
5

Wykonaj poniższe kroki:

    1. Upewnij się, że usunięto całą zawartość folderu jar znajdującego się w Twoim lokalnym, z wyjątkiem jar, który chcesz zachować.
      Na przykład pliki takie jak .repositories, .pom, .sha1, .lastUpdated itp.
    1. Wykonaj mvn clean install -opolecenie

Pomoże to w korzystaniu z plików jar lokalnego repozytorium zamiast łączenia się z jakimkolwiek repozytorium.

— Madhu
źródło
1
Usuwanie tylko *.repositoriesi *.sha1pliki działały dla mnie
— DLight
4

W moim przypadku miałem projekt wielomodułowy, tak jak Ty. Musiałem zmienić identyfikator grupy jednej z zewnętrznych bibliotek, od których zależał mój projekt, jak pokazano poniżej.

Z:

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

Do:

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

Zwróć uwagę na sekcję <groupId>. Okazało się, że zapomniałem zmodyfikować odpowiednią sekcję podmodułów, które definiują tę zależność w swoich plikach pom.

Doprowadziło mnie to do szału, ponieważ moduł był dostępny lokalnie.

— Willa
źródło
2

Opcja -o nie zadziałała dla mnie, ponieważ artefakt jest nadal w fazie rozwoju i nie został jeszcze przesłany, a maven (3.5.x) nadal próbuje pobrać go ze zdalnego repozytorium, ponieważ jest to pierwszy raz, zgodnie z błędem, który otrzymuję.

Jednak to naprawiło to dla mnie: https://maven.apache.org/general.html#importing-jars

Po tej ręcznej instalacji nie ma również potrzeby korzystania z opcji offline.

AKTUALIZACJA

Właśnie odbudowałem zależność i musiałem ją ponownie zaimportować: zwykły mvn clean installnie był dla mnie wystarczający

— Luigi Cristalli
źródło
2

Nawet biorąc pod uwagę wszystkie powyższe odpowiedzi, nadal możesz napotkać problemy, które spowodują zakończenie kompilacji offline Mavena z błędem. W szczególności może pojawić się ostrzeżenie, takie jak:

[WARNING] The POM for org.apache.maven.plugins:maven-resources-plugin:jar:2.6 is missing, no dependency information available

Po ostrzeżeniu natychmiast pojawią się dalsze błędy i maven zakończy pracę.

Dla nas najbezpieczniejszym sposobem budowania offline z pamięcią podręczną maven offline utworzoną zgodnie z powyższymi wskazówkami jest użycie następujących parametrów offline maven:

mvn -o -llr -Dmaven.repo.local=<path_to_your_offline_cache> ...

Szczególnie opcja -llr zapobiega konieczności dostrajania lokalnej pamięci podręcznej, jak zaproponowano w odpowiedzi nr 4.

Zwróć również uwagę, aby parametr localRepository w settings.xml był ustawiony w następujący sposób:

<localRepository>${user.home}/.m2/repository</localRepository>
— ThoR
źródło
0

Miałem dokładnie ten sam problem. Działa mvn clean installzamiast mvn clean compilego rozwiązać. Różnica występuje tylko w przypadku korzystania z multi-maven-project, ponieważ zależności projektu są przekazywane do repozytorium lokalnego przy użyciu install.

— GJohannes
źródło
-1

Maven zawsze najpierw sprawdza lokalne repozytorium, jednak twoja zależność musi być zainstalowana w repozytorium, aby maven mógł ją znaleźć.

mvn installNajpierw uruchom moduł zależności, a następnie skompiluj moduł zależny.

— Oliver
źródło
1
Zredagowałem moje pytanie, aby pokazać, że artefakt znajduje się w repozytorium (zwróć uwagę na polecenie „ls -al”, które wykonuję. Mimo to Maven i tak próbuje je pobrać. Jakieś inne pomysły?
— Dave
6
@Oliver: brakuje ci faktu, że w przypadku artefaktów w lokalnym repozytorium Maven może nadal sprawdzać zdalne repozytoria, jeśli artefakt jest zbyt starym migawką.
— Andreas Veithen
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.