Maven ne parvient pas à trouver l'artefact local

Question

Occasionnellement, maven se plaint qu'une dépendance particulière, qui est construite et empaquetée localement, ne peut être trouvée dans le dépôt local lors de la construction d'un autre projet qui l'a comme dépendance. Nous obtenons une erreur du type :

Échec de l'exécution de l'objectif sur le projet X : Impossible de résoudre les dépendances pour le projet X : Impossible de trouver Y dans [référentiel archiva] a été mis en cache dans le référentiel local, la résolution ne sera pas réessayée avant que l'intervalle de mise à jour interne ne se soit écoulé ou que les mises à jour soient forcées ->.

Où X est le projet en cours de construction, et Y est l'artefact supposé manquant. Si vous regardez dans le référentiel local, l'artefact est là. Cet artefact n'est jamais installé dans notre référentiel archiva, donc le problème est purement basé dans le référentiel local.

Nous avons essayé différents profils dans settings.xml, et bien sûr "mvn -U". Ni l'un ni l'autre ne sont utiles, et ils ne devraient pas l'être puisque cet artefact ne va jamais plus loin que le dépôt local.

Les deux seules choses qui semblent fonctionner sont d'attendre un temps très long jusqu'à ce que maven devienne intelligent, ou de supprimer complètement le dépôt local. L'option d'attente est probablement liée à l'intervalle de mise à jour susmentionné.

Nous avons rencontré ce problème avec maven 3.0.2 et 3.0.3. Nous utilisons Archiva 1.0.3 (mais là encore, cela ne devrait pas être un facteur). Toute aide serait grandement appréciée.

Answer 1

J'avais DependencyResolutionException dans Ubuntu Linux lorsque j'ai installé des artefacts locaux via un shell script. La solution était de supprimer les artefacts locaux et de les installer à nouveau "manuellement" - en appelant mvn install:install-file via le terminal.

Answer 2

C'est arrivé parce que j'avais http au lieu de https dans ce :

<repository>
    <id>jcenter</id>
    <name>jcenter-bintray</name>
    <url>https://jcenter.bintray.com</url>
</repository>

Answer 3

Vérifiez si votre artefact Y a un packaging défini comme "jar". Si vous l'avez défini comme "war" par erreur ou par copier-coller, il affichera cet étrange "a été mis en cache dans le référentiel local, la résolution ne sera pas réessayée avant que l'intervalle de mise à jour interne ne se soit écoulé ou que les mises à jour soient forcées". Je m'attendrais à quelque chose comme "artefact Y est war, type jar attendu".

Answer 4

Dans mon cas, j'avais besoin que le projet Y soit un WAR pour être déployé via Tomcat, et qu'il soit un JAR pour pouvoir l'ajouter comme dépendance dans le projet X.

Donc, dans le projet Y pom.xml J'ai ajouté ce plugin pour créer un JAR avec le WAR :

            <plugin>
                <artifactId>maven-war-plugin</artifactId>
                <version>3.2.2</version>
                <configuration>
                    <attachClasses>true</attachClasses>
                    <classesClassifier>classes</classesClassifier>
                </configuration>
            </plugin>

Et en ajoutant la dépendance du projet Y dans le projet X pom.xml j'ai dû ajouter un classifier :

        <dependency>
            <groupId>groupId.of.project.Y</groupId>
            <artifactId>project.Y</artifactId>
            <version>1.0-SNAPSHOT</version>
            <classifier>classes</classifier>
        </dependency>

Note : lorsque vous construisez le projet Y, vous verrez 2 packagings dans le dossier cible : project-Y.war y project-Y-classes.jar C'est pourquoi, lors de l'importation, vous devez spécifier le nom de l'utilisateur. classes pour importer le JAR et non le WAR.

Answer 5

J'ai eu la même erreur pour une cause différente : J'avais créé un POM de démarrage contenant nos dépendances de "bonne pratique", et je l'ai construit et installé localement pour le tester. Je pouvais le "voir" dans le dépôt, mais un projet qui l'utilisait obtenait l'erreur ci-dessus. Ce que j'avais fait, c'était de définir le POM de démarrage comme pom, donc il n'y avait pas de JAR. Maven avait raison de dire qu'il n'était pas dans Nexus -- mais je ne m'attendais pas à ce qu'il le soit, donc l'erreur était, hummm, inutile. En changeant le POM de démarrage pour un packaging normal et en réinstallant, le problème est résolu.