web-dev-qa-db-fra.com

maven deploy: échec du déploiement du fichier (conflit 409), mais le téléchargement des artefacts a réussi

REMARQUE:

Je me rends compte maintenant que le pot a été placé dans mon référentiel, mais pas le pom.xml. Maintenant, j'ai un autre projet où le pom.xml ne parvient pas à être promu, mais le pot est placé dans le référentiel.

Cependant, un autre projet, le pom.xml et le bocal sont placés dans le référentiel.

J'ai un projet à Jenkins où j'utilise le plugin de promotion pour déployer mes artefacts dans Maven via le deploy:deploy-file objectif.

Cela fonctionne pour plusieurs autres projets que j'ai à Maven, mais cela échoue pour ce projet. Le plus drôle, c'est que le fichier (mais pas le pom.xml) est quand même téléchargé. J'ai vérifié cela en supprimant l'artefact de notre référentiel Maven, puis en exécutant la promotion. L'artefact est dans notre référentiel après la promotion.

Voici le journal que je reçois. Brisé les lignes extra longues du mieux que j'ai pu:

[workspace] $ /bin/bash -xe /opt/Tomcat/Apache-Tomcat-7.0.27/temp/hudson7357923598740079329.sh
+ FILE_LOC=/mnt/jenkins/builds/metricsdb-trunk/21/archive/target/archive
+ mvn deploy:deploy-file
    -Dversion=0.8.0
    -Dfile=/mnt/jenkins/builds/metricsdb-trunk/21/archive/target/archive/metricsdb-etl.jar
    -DpomFile=/mnt/jenkins/builds/metricsdb-trunk/21/archive/target/archive/pom.xml
    -Durl=http://repo.vegicorp.com/artifactory/ext-release-local -DrepositoryId=VegiCorp
[INFO] Scanning for projects...
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building Command Line Spring Batch Module 0.8.0.CI-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- maven-deploy-plugin:2.7:deploy-file (default-cli) @ metricsdb-etl ---
Uploading: http://repo.vegicorp.com/artifactory/ext-release-local/com/vegicorp/batch/metricsdb/metricsdb-etl/0.8.0/metricsdb-etl-0.8.0.jar
2/38 KB   
4/38 KB   
[...]

Uploaded: http://repo.vegicorp.com/artifactory/ext-release-local/com/vegicorp/batch/metricsdb/metricsdb-etl/0.8.0/metricsdb-etl-0.8.0.jar (38 KB at 202.2 KB/sec)
Uploading: http://repo.vegicorp.com/artifactory/ext-release-local/com/vegicorp/batch/metricsdb/metricsdb-etl/0.8.0/metricsdb-etl-0.8.0.pom
2/7 KB     
4/7 KB   
[...]

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.243s
[INFO] Finished at: Thu Oct 04 14:38:52 CDT 2012
[INFO] Final Memory: 4M/119M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.Apache.maven.plugins:maven-deploy-plugin:2.7:deploy-file
    (default-cli) on project metricsdb-etl: Failed to deploy artifacts:
    Could not transfer artifact com.vegicorp.batch.metricsdb:metricsdb-etl:pom:0.8.0 from/to
    VegiCorp (http://repo.vegicorp.com/artifactory/ext-release-local):
    Failed to transfer file: http://repo.vegicorp.com/artifactory/ext-release-local/com/vegicorp/batch/metricsdb/metricsdb-etl/0.8.0/metricsdb-etl-0.8.0.pom.
    Return code is: 409, ReasonPhrase:Conflict. -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.Apache.org/confluence/display/MAVEN/MojoExecutionException
failed build hudson.tasks.Shell@24a6e7f9 SUCCESS
Finished: FAILURE

La sortie avec l'indicateur de débogage (-X) est dans Pastebin .

mavendeployment
34
David W.

J'ai trouvé le problème. Deux problèmes en fait:

  • Je n'avais que la configuration du référentiel de versions et j'essayais d'enregistrer une version d'instantané dans le référentiel de versions. Artifactory a été configuré pour autoriser uniquement les versions dans le référentiel de versions. Cela peut être modifié dans le cadre Artifactory, mais j'ai décidé contre cela.

  • Ma pom.xml contient une version différente de celle que j'essayais d'enregistrer. Par exemple, le pom.xml a indiqué la version 2.0 et j'essayais d'enregistrer la version en tant que 2.0.2. Artifactory a rejeté le pom (mais pas le pot) pour cette raison.

J'ai trouvé le paramètre Artifactory (qui est par référentiel) qui demande s'il faut "supprimer les vérifications de cohérence POM". Cocher cette case me permettra de définir la version sur un, mais demander au pom d'en dire un autre.

J'ai également dû modifier mon fichier "settings.xml" Maven pour permettre à la fois un référentiel Release et Snapshot. Je dois également modifier mon URL vers le référentiel d'instantanés.

Nous n'utilisions Ivy que depuis un certain temps (qui n'a pas de concept d'instantané ), donc nous ne faisions que mettre des choses dans le référentiel de versions. Il s'agit d'un projet Maven, et le développeur a marqué la version dans le POM comme INSTANTANÉ.

Malheureusement, la documentation de Maven est assez pauvre, et il n'y a toujours pas de bons livres sur Maven. Pire encore, les messages d'erreur sont tout simplement médiocres. Que signifie " 409, ReasonPhrase: Conflict. -> [Aide 1] " signifie?

Non pas que la documentation Ivy soit tellement meilleure, mais Ant in Action a d'excellentes sections sur l'utilisation d'Ivy.

34
David W.

Assurez-vous que vous incluez -SNAPSHOT dans votre version si vous publiez dans le référentiel d'instantanés.

21
B5A7

Ouais ... Raison multiple pour la même erreur. Peut-être que cela aidera quelqu'un

1. Login as Admin to Artifactory
2. Configuration -> Repositories
3. Edit the Local Repository ---> Suppress POM Consistency Checks

Cela résout mon problème ... Pas sûr. Bonne approche ou non?

4
Shineed Basheer

Je suis également confronté à ce problème et j'ai trouvé la raison pour laquelle le projet parent n'a pas été déployé dans le référentiel d'instantanés. J'exécute mvn deploy dans le dossier parent et le problème est résolu.

4
Yingchu

Avait aussi ce message d'erreur. Pour moi, le problème était que la configuration du serveur consiste à n'accepter que la version, pas le SNAPSHOT. Après avoir retiré l'INSTANTANÉ du pom, cela a bien fonctionné.

2
wouter

Dans mon cas, le fichier POM associé au fichier jar (externe, dans le même répertoire) avait une dépendance à lui-même. Il s'agissait d'un repo zippé hors ligne d'un tiers que je devais charger dans artificiel.

J'ai modifié les fichiers POM, supprimé l'auto-dépendance et vérifié que les informations sur le package étaient correctes. Ensuite, les artefacts se sont déployés sans problème. Envoyé un e-mail au fournisseur afin qu'il puisse corriger sa version.

1
Bill Dolan

J'avais aussi ce problème et il s'est avéré que nous avions des règles d'inclusion/exclusion configurées sur le référentiel sur lequel j'essayais de déployer et mon déploiement ne correspondait pas à ces règles.

Ma solution était de pointer le déploiement vers un nouveau référentiel qui avait **/* comme règle d'inclusion (et le modèle de mon autre référentiel comme règle d'exclusion pour les garder séparés).

1
user11348207

Il y a une bonne possibilité que l'espace sur votre dépôt à distance soit plein. Vérifiez cela avant d'aller tout le temps technique et perdre. Gaspillé 2-3 heures pensant que c'était un problème logique.

0
anuj pradhan

J'ai rencontré le même problème. (TL; DR: solution voir dernière ligne)

Lors du déploiement de jenkins vers Artifactory, parfois (magique!) Une erreur de conflit 409 apparaissait avec le message d'erreur suivant dans le journal Artifactory:

[AVERTISSEMENT] (o.a.e.UploadServiceImpl: 239) - Envoi du code d'erreur HTTP 409: La stratégie de somme de contrôle 'LocalRepoChecksumPolicy: CLIENT' a rejeté l'artefact 'gradle-integration: com.redacted.Java/fooProject/123/foo-123.jar'. Checksums info: ChecksumsInfo {checksums = {SHA-1 = ChecksumInfo {type = SHA-1, original = 'da39a3ee5e6b4b0d3255bfef95601890afd80709', actuel = '1459689f0be058f4ecef7e6fe3576f1550a8afd8f98_f8_f8_f8_f 14c7a498de028d6eb5882b3c698bc456 '}}}.

Comme l'œil averti pourrait le remarquer: le MD5 # d41d8cd98f00b204e9800998ecf8427e est la somme de contrôle d'un fichier ou d'une chaîne vide.

Ce qui signifie que les événements suivants doivent se produire: Le travail de copie qui prépare les artefacts dans le dossier de publication n'était pas terminé et le fichier était donc vide lors du calcul de la somme de contrôle.

Cependant, lorsque le déploiement s'est produit, le fichier était là, Artifactory reçoit maintenant une somme de contrôle incorrecte et refuse correctement le fichier avec le code d'erreur 409.

LA SOLUTION (est simple): assurez-vous à 100% que les fichiers sont bien là avant de démarrer le travail de déploiement (ajoutez une pause ou une logique appropriée).

0
fl0w