Comment forcer Maven à utiliser mon référentiel local plutôt que d'aller vers des dépôts distants pour récupérer des artefacts?

97

J'utilise Maven 3.3.3 avec Java 8 sur Mac Yosemite. J'ai un projet multi-module.

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

Lorsque je construis l'un de mes modules enfants, par exemple, "mon-module" ci-dessus, en utilisant "mvn clean install", la construction tente de télécharger les artefacts du module enfant à partir d'un référentiel distant que j'ai défini dans mon ~ / .m2 Fichier /settings.xml. La sortie est ci-dessous

[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

Comment forcer Maven à vérifier mon dépôt local ~ / .m2 / avant d'essayer de télécharger à partir des dépôts distants? Voici où j'ai mes dépôts distants définis dans mon fichier ~ / .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>

Edit: En réponse à la réponse disant que le téléchargement se produit lorsque l'artefact n'est pas là, voici la sortie du terminal dans laquelle je prouve que le fichier était là dans mon dépôt mais Maven essaie de le télécharger quand même ...

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
source
2
Maven fait vérifier votre dépôt local avant d' essayer de télécharger un artefact d'un dépôt distant. Êtes-vous sûr que votre section locale possédait ces artefacts avant d'essayer cette version? Vous pouvez inspecter votre référentiel local maintenant et réessayer quand même une autre version. En outre, vous pouvez spécifier l'emplacement de votre référentiel local dans le settings.xml(voir ici ).
— mystarrocks
Bien que je n'ai pas spécifié mon référentiel dans mon fichier settings.xml, c'est la valeur par défaut que Maven a configurée pour moi - ~ / .m2 / repository. Dois-je le spécifier même s'il s'agit de la valeur par défaut?
— Dave
Pour moi, il y a d'autres fichiers dans mes référentiels locaux, tels que * .sha1 ou * .lastUpdate. supprimer d'autres fichiers sauf * .jar et * .pom empêchera maven de re-télécharger le fichier à partir du référentiel distant
— Harun

Réponses:

45

La dépendance a une version d'instantané. Pour les instantanés, Maven vérifiera le référentiel local et si l'artefact trouvé dans le référentiel local est trop ancien, il tentera d'en trouver un mis à jour dans les référentiels distants. C'est probablement ce que vous voyez.

Notez que ce comportement est contrôlé par la updatePolicydirective dans la configuration du référentiel (qui est dailypar défaut pour les référentiels d'instantanés).

— Andreas Veithen
source
16
Est-il possible de "remplacer" ceci par l'argument de commande de console? Comme: mvn clean install -FORCE_COMMAND
— Naxos84
21
«Trop vieux» veut dire quoi? Il choisit le dernier instantané qu'il peut trouver, qu'il soit local ou distant? Ce serait sûrement un comportement horrible. Si je viens de créer un instantané, je veux vraiment utiliser celui-là, pas celui que la construction CI a construit juste un instant plus tard.
— Tom Quarendon
Veuillez expliquer davantage ce que signifie «trop vieux»?
— Đỗ Công Bằng
32

Utilisation mvn --help et vous pouvez voir la liste des options.

Il existe une option comme -nsu,--no-snapshot-updates Suppress SNAPSHOT updates

Donc, utilisez la commande mvn install -nsupeut forcer la compilation avec le référentiel local.

— Zheng Zhongqi
source
10
Vous pouvez également utiliser -opour le comportement maven "hors ligne"
— Sean
8
L'option -nsu n'empêche pas mvn d'essayer et de ne pas télécharger un artefact à distance s'il n'a pas encore été téléchargé au lieu d'utiliser la construction locale comme lorsque l'artefact a été construit et installé localement. -
— user1767316
J'ai eu le même problème avec un artefact qui n'était pas encore téléchargé et cela l'a corrigé pour moi: maven.apache.org/general.html#importing-jars
— Luigi Cristalli
15

Pour vraiment forcer maven à n'utiliser votre repo local, vous pouvez courir avec . Le dit à maven de vous laisser travailler «hors ligne», et il restera hors du réseau.mvn <goals> -o-o

— Sean
source
5
L'option -o n'empêche pas mvn d'essayer et de ne pas télécharger un artefact à distance s'il n'a pas encore été téléchargé au lieu d'utiliser la construction locale comme lorsque l'artefact a été construit et installé localement.
— user1767316
2
c'est vrai - si vous n'avez pas de copie locale, vous n'avez pas de chance. Ceci est utile pour les projets que vous avez déjà construits, mais qui ont potentiellement des changements SNAPSHOT récents dont vous ne vous souciez pas.
— Sean
Ou même si vous n'avez jamais construit le projet, vous pouvez vous préparer à le construire hors ligne avecmvn dependency:go-offline
— Aldian
Que faire si vous avez une copie locale que vous venez d'installer (elle n'est donc jamais déployée / disponible dans le dépôt d'instantanés distant)?
— Vivek Chavda
1
Ah, je viens de créer un projet pom avec une collection de dépendances, mais je n'ai pas spécifié <type> pom </type> dans le projet consommateur, donc il cherchait un fichier jar (et bien sûr ne pouvait pas le trouver, même en mode hors ligne)
— Vivek Chavda
4

Dans mon cas, j'avais un projet multi-modules comme vous. J'ai dû changer un identifiant de groupe de l'une des bibliothèques externes dont dépendait mon projet, comme indiqué ci-dessous.

De:

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

À:

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

Faites attention à la section <groupId>. Il s'est avéré que j'oubliais de modifier la section correspondante des sous-modules qui définissent cette dépendance dans leurs fichiers pom.

Cela m'a rendu très fou car le module était disponible localement.

— Willa
source
4

Suivez les étapes ci-dessous:

    1. Assurez-vous de supprimer tout le contenu du dossier jar situé dans votre fichier local, à l'exception du fichier jar que vous souhaitez conserver.
      Par exemple, des fichiers comme .repositories, .pom, .sha1, .lastUpdated etc.
    1. Exécuter la mvn clean install -ocommande

Cela aidera à utiliser les fichiers jar du référentiel local plutôt que de se connecter à un référentiel.

— Madhu
source
1
La suppression uniquement *.repositorieset les *.sha1fichiers ont fonctionné pour moi
— DLight
2

L'option -o n'a pas fonctionné pour moi car l'artefact est toujours en développement et pas encore téléchargé et maven (3.5.x) essaie toujours de le télécharger à partir du référentiel distant car c'est la première fois, selon l'erreur que j'obtiens.

Cependant, cela a résolu le problème pour moi: https://maven.apache.org/general.html#importing-jars

Après cette installation manuelle, il n'est pas non plus nécessaire d'utiliser l'option hors ligne.

METTRE À JOUR

Je viens de reconstruire la dépendance et j'ai dû la réimporter: le régulier mvn clean installne me suffisait pas

— Luigi Cristalli
source
-1

Maven vérifie toujours votre référentiel local en premier, cependant, votre dépendance doit être installée dans votre référentiel pour que maven la trouve.

Exécutez mvn installd'abord votre module de dépendance, puis créez votre module dépendant.

— Oliver
source
1
J'ai édité ma question pour montrer que l'artefact est dans le dépôt (notez la commande "ls -al" que j'exécute. Pourtant, Maven tente de le télécharger quand même. D'autres idées?
— Dave
5
@Oliver: il vous manque le fait que pour les artefacts dans le référentiel local, Maven peut toujours consulter les référentiels distants si l'artefact est un instantané trop ancien.
— Andreas Veithen
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.