Maven: échec de lecture du descripteur d'artefact

J'espère que quelqu'un pourra m'aider avec un problème avec lequel je me bats.

Lorsque j'essaie de créer mon projet à partir du terminal, j'obtiens cette erreur:

Failed to read artifact descriptor for com.morrislgn.merchandising.common:test-data-utils:jar:0.3b-SNAPSHOT: Could not find artifact com.morrislgn.merchandising:merchandising:pom:0.3b-SNAPSHOT

Le common.test-data-utilspot est créé par un projet distinct et partagé entre celui-ci et un autre projet (l'autre projet ne se construit pas non plus, mais cela est dû à un autre problème).

Je peux construire com.morrislgn.merchandising.common:test-data-utilssans problème, je peux voir l'entrée qu'il fait dans le .m2référentiel local sur ma machine. J'ai également réindexé mon référentiel dans Eclipse.

Le POM de mon projet a cette entrée:

<dependency>
    <groupId>com.morrislgn.merchandising.common</groupId>
    <artifactId>test-data-utils</artifactId>
    <version>0.3b-SNAPSHOT</version>
</dependency>

Ce qui me semble correct - le POM ne signale aucune erreur non plus lorsqu'il est affiché dans Eclipse.

Quelqu'un peut-il me dire ce que je manque ici ou que je fais mal?

Vous pouvez toujours essayer mvn -U clean install

-U force la vérification des mises à jour et des instantanés des référentiels distants.

Ce problème peut se produire si vous avez des projets enfants qui font référence à un pom parent et que vous n'avez pas installé à partir du répertoire pom parent (exécuté à mvn installpartir du répertoire parent). L'un des projets enfants peut dépendre d'un projet frère et quand il va lire le pom du frère, il échouera avec l'erreur mentionnée dans la question à moins que vous n'ayez installé à partir du répertoire pom parent au moins une fois.

Je viens de rencontrer ce problème lors du déplacement d'un projet vers un nouvel ordinateur. J'avais l'habitude d'exécuter des commandes à partir du projet enfant et je n'ai pas exécuté l'installation sur le parent.

A eu le même problème avec IntelliJ IDEA et les suivants ont fonctionné.

• Aller à File
• Sélectionner Settings
• Sélectionner Build, Execution, Deployments
• Sélectionnez Build Toolsdans le menu déroulant
• Sélectionnez Mavendans le menu déroulant
• Cochez la Always update snapshotscase

Si vous utilisez Eclipse, faites un clic droit sur votre projet -> Maven -> Mettre à jour le projet . Cela ouvrira la boîte de dialogue Mettre à jour le projet Maven.

Dans cette boîte de dialogue, cochez la case Forcer la mise à jour des instantanés / versions et cliquez sur OK . (Veuillez vous référer à l'image ci-dessous)

Cela a fonctionné pour moi!

Si vous utilisez eclipse, faites un clic droit sur projet -> propriétés -> Maven et assurez-vous que la case " Résoudre les dépendances des projets d'espace de travail " n'est pas cliquée.

J'espère que cela t'aides.

Je sais que je suis assez en retard pour la conversation, mais j'ai aussi eu ce problème. Je pense que le problème était le pare-feu de mon entreprise. Ma solution était de débrancher le réseau, de se connecter à notre réseau sans fil ouvert, puis de forcer une mise à jour via Eclipse. Cela a tout résolu.

J'ai eu le même problème avec eclipse où la ligne de commande maven build fonctionnait très bien MAIS essayez ceci

• aller dans .m2 / repository et effacer le répertoire associé
• exécuter les dépendances de mise à jour de maven dans eclipse

L'erreur disparaît .... pourquoi ma ligne de commande mvn fonctionnait avec ces répertoires et eclipse .m2eclipse ne pouvait pas, je n'en ai aucune idée et ça craint un peu. Mon projet fonctionne à nouveau dans eclipse.

J'ai eu le même problème avec IntelliJ. J'ai résolu avec un clic droit sur pom.xml> Maven> Reimport

J'ai résolu ce problème en supprimant dans les dossiers du référentiel où cette erreur a été affichée tout sauf les fichiers .jar et .pom.

Les problèmes "Impossible de lire le descripteur d'artefact" indiquent généralement un problème avec le fichier pom de la dépendance dans le référentiel maven. Je vous suggère de vérifier si le nom du fichier pom est le même que celui que maven attend, et également de vérifier si le contenu du fichier pom est valide.

Pour moi, c'était lié à la définition du "User Setting.xml" à l'intérieur

Window > preferences > Maven > User Settings > and then browsing to the user Settings inside the { maven unarchived directory / }/apache-maven-2.2.1/conf/settings.xml . 

J'ai un projet

 A/
 |--a1
 |--a2

Maintenant, il y a un autre projet dans notre organisation

 B/
 |--b1
 |--b2
 |--b3

(Chaque module a1, b1 etc. et les projets parents A, B ont leur propre pom.xml selon les règles maven standard des parents et des enfants)

Les deux projets sont extraits sur mon éclipse locale (de SVN). Je travaille activement sur A.

J'ai appris qu'il existe une bonne fonctionnalité commune (b4) développée en B et que je devais l'utiliser.

 B/
 |--b1
 |--b2
 |--b3
 |--b4 (NEW)

Les développeurs de b4 ont déployé ce module b4 comme un artefact dans le référentiel de notre organisation. J'ai inclus la dépendance au POM de mon module, c'est-à-dire le pom.xml de a2. Eclipse a téléchargé l'artefact requis depuis le dépôt et j'ai pu y importer les classes.

Maintenant, le problème commence ... Je devais vérifier le code source de b4 dans un but précis et comme j'avais déjà vérifié B sur mon éclipse locale, je l'ai mis à jour depuis SVN et extrait le module b4. J'ai également exécuté pom.xml du module b4 avec des cibles telles que clean, package etc. Après un certain temps, lorsque j'ai terminé mon codage, j'avais besoin de créer un JAR de mon module a2. J'ai couru "package" sur pom.xml et BAM de a2 !! erreurs n erreurs pour le module a2. Ces erreurs n'étaient pas non plus très conviviales. La seule chose est qu'il y avait certainement le nom de b4 dans les journaux.

Solution: Après avoir essayé de nombreuses solutions pendant de nombreuses heures, j'ai exécuté "mvn -U clean install" à partir de la console dans la direction du projet de mon B (c'est-à-dire dans ../codebase/B). Comme B est le parent, la commande clean install s'est exécutée pour tous les modules, y compris b4, et s'est exécutée avec succès. Après cela, j'ai exécuté "mvn -U clean install" pour mon projet parent qui est A. Et cela a fonctionné! le module a2 a été compilé, installé, (empaqueté plus tard) avec succès.

Ici, le point important était que si b4 est dans votre espace de travail, n'installez pas seulement b4. Vous devrez nettoyer l'installation complète B. Je suis venu à cette solution après avoir lu la réponse de Zuill

EDIT: Encore une chose ici pour noter que si je n'avais pas fait vérifier le projet B dans l'environnement local, alors ce problème ne se serait peut-être pas produit pour moi. J'ai tendance à penser que cela s'est produit car j'ai fait vérifier B dans mon espace de travail local.

Vous mentionnez deux groupIds différents, com.morrislgn.merchandising.commonet com.johnlewis.jec.webpim.common. C'est peut-être le problème.

Erreur de référence Maven "Échec du transfert ..."

find ~/.m2  -name "*.lastUpdated" -exec grep -q "Could not transfer" {} \; -print -exec rm {} \;

N'a pas eu de chance de mise à jour via eclipse. J'ai dû utiliser mvn clean install -U (qui a tout résolu).

Pour moi, cela semble avoir été un problème avec la dépendance POM.

J'ai travaillé dessus en utilisant le référentiel virtuel jitpack, avec lequel vous pouvez inclure des référentiels github basés sur leur URL au lieu de leur propre POM (qui semble avoir été erroné dans mon cas).

    <repository>
        <id>jitpack.io</id>
        <url>https://jitpack.io</url>
    </repository>

J'ai eu le même problème pendant un certain temps et malgré cela, mvn -U clean installle problème n'était pas résolu!

J'ai finalement résolu le problème en supprimant tout le .m2dossier, puis j'ai redémarré mon IDE et le problème avait disparu!

Donc, parfois, le problème augmentait en raison d'incompatibilités ou de problèmes dans votre référentiel maven local.

Dans notre cas, l'erreur est apparue en raison du changement de nom incorrect de groupId alors que certains des projets de la configuration Maven multi-module font référence à d'autres.

Nous avions un projet d'agrégateur ( billing-parent) avec deux modules ( billing-api, billing):

com.company.team:billing-parent
|-com.company.team:billing-api
|-com.company.team:billing

Le projet billingdépend billing-api. Donc, en son sein, pom.xmlil y avait:

<dependency>
    <groupId>com.company.team</groupId>
    <artifactId>billing-api</artifactId>
    <version>${project.version}</version>
</dependency>

Nous avons décidé de renommer groupId de com.company.teamà com.company.team.billing. Nous avons remplacé l'ancienne valeur dans celle des parents pom.xmlet dans les <parent>sections des deux modules. Mais j'ai oublié de mettre à jour la dépendance ci-dessus. Nous avions donc une configuration dans laquelle le billingprojet fait référence à un ancien billing-apiartefact. Finalement, il lance la construction du billingmodule après un certain temps avec l'erreur comme

[ERROR] Failed to execute goal on project billing: Could not resolve dependencies for project com.company.team.billing:billing:jar:3.5.1-SNAPSHOT: Failed to collect dependencies at com.company.team:billing-api:jar:3.5.1-SNAPSHOT: Failed to read artifact descriptor for com.company.team:billing-api:jar:3.5.1-SNAPSHOT: Failure to find <parent of the com.company.team:billing-parent project which is not available any more>

malgré le fait que le billing-apimodule se construit sans erreurs.

Solution 1: changement de nom groupIden dependencyaussi bien.

Solution 2: remplacez groupIdpar la ${project.groupId}propriété comme ceci:

<dependency>
    <groupId>${project.groupId}</groupId>
    <artifactId>billing-api</artifactId>
    <version>${project.version}</version>
</dependency>

Conclusion. Donc, mon conseil au cas où vous rencontriez l'erreur dans la configuration multi-module devrait être: vérifiez soigneusement groupIdet artifactIddes dépendances sur les modules voisins.

Naviguez via le shell à l'intérieur de votre dossier de projet et exécutez la commande suivante:

mvn -U clean install

Habituellement, cela devrait déjà résoudre votre problème.

Si vous voyez un message comme celui-ci:

Impossible de résoudre les dépendances pour le projet: war: 0.0.1-INSTANTANÉ: Échec de la collecte des dépendances sur com.sun.jersey: jersey-server: jar: 1.9

Exécutez ensuite:

export MAVEN_OPTS=-Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2

suivi par:

mvn -U clean install

à nouveau pour enfin mettre à jour vos dépendances.

Ensuite, effectuez une construction propre de Maven:

maven clean install

J'avais un problème similaire. Dans mon cas, la version de testng dans mon dossier .m2 / repositories était corrompue, mais quand je l'ai supprimé et refait une mise à jour maven, tout a bien fonctionné.

J'ai eu ce problème dans éclipse, mvn -U clean installn'a pas fonctionné, mais en cliquant avec le bouton droit sur le projet et en sélectionnant Maven-> Mettre à jour le projet, il a été résolu.

Je viens de commencer à utiliser STS Eclipse avec la première fois avec Maven. Le projet que j'ai configuré avait déjà son propre fichier settings.xml. Si tel est le cas, vous souhaiterez mettre à jour votre fichier settings.xml dans la configuration d'exécution.

1. faites un clic droit sur pom.xml et "Exécuter en tant que" -> "Exécuter les configurations ..."

2. où il est dit "Paramètres utilisateur", cliquez sur le bouton Fichier et ajoutez le fichier settings.xml.

3. Je pense que cela est spécifique à votre projet, mais mes "objectifs" sont définis sur "installation propre" et j'ai vérifié sur "Ignorer les tests".

Cette erreur signifie essentiellement que maven n'a pas pu lire une certaine dépendance à partir du référentiel local. Cela pourrait arriver parce qu'un fichier jar n'a pas été téléchargé correctement. Alors, allez dans votre référentiel local maven et assurez-vous qu'il n'y a pas de fichier d'extension .lastUpdated .

Cela m'a aidé:

Depuis l'IDE (Red Hat CodeReady Studio dans mon cas).

Windows -> Afficher la vue -> Terminal -> Ouvrir / ajouter un terminal local

Exécutez les commandes comme suit>

$ cd /pom-file-path/

$ mvn -U clean install

J'ai résolu ce problème en modifiant le maven setting.xml et le référentiel