Echec du plugin Maven Release: artefacts source déployés deux fois
Nous utilisons le plugin maven release sur hudson et essayons d’automatiser le processus de publication . Lorsque nous essayons d'effectuer la publication: perform, elle échoue car elle tente de télécharger un artefact source deux fois dans le référentiel.
Les choses que j'ai essayées
- suppression du profil contenant le plugin source maven du super pom (ne fonctionnait pas)
- spécifiant les objectifs de hudson pour publication comme version de -P! attach-source: prepare release: perform. Je pensais que cela empêcherait le plugin source de s'exécuter. (n'a pas marché).
- essayé de spécifier la phase du plug-in à une phase non existante dans le super-pom. (n'a pas fonctionné)
- essayé de spécifier la configuration du plug-in, forReleaseProfile sur false. (devinez quoi ?? n'a pas fonctionné aussi)
Il crache toujours cette erreur.
[INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http
[INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http
[INFO] [DEBUG] Checking for pre-existing User-Agent configuration.
[INFO] [DEBUG] Adding User-Agent configuration.
[INFO] [DEBUG] not adding permissions to wagon connection
[INFO] Uploading: http://xx.xx.xx.xx:8081/nexus/content/repositories/releases//com/yyy/xxx/hhh/hhh-hhh/1.9.40/hhh-hhh-1.9.40-sources.jar
[INFO] 57K uploaded (xxx-xxx-1.9.40-sources.jar)
[INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http
[INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http
[INFO] [DEBUG] Checking for pre-existing User-Agent configuration.
[INFO] [DEBUG] Adding User-Agent configuration.
[INFO] [DEBUG] not adding permissions to wagon connection
[INFO] Uploading: http://xx.xxx.xx.xx:8081/nexus/content/repositories/releases//com/xxx/xxxx/xxx/xxx-xxx/1.9.40/xxx-xxx-1.9.40-sources.jar
[INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [ERROR] BUILD ERROR
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Error deploying artifact: Authorization failed: Access denied to: http://xx.xxx.xx.xx:8081/nexus/content/repositories/releases/com/xxx/xxx/xxx/xxx-config/1.9.40/xxx-xxx-1.9.40-sources.jar
Toute aide à ce sujet sera vraiment appréciée.
Essayez d’exécuter mvn -Prelease-profile help:effective-pom. Vous constaterez que vous avez deux sections d’exécution pour maven-source-plugin
La sortie ressemblera à ceci:
<plugin> <artifactId>maven-source-plugin</artifactId> <version>2.0.4</version> <executions> <execution> <id>attach-sources</id> <goals> <goal>jar</goal> </goals> </execution> <execution> <goals> <goal>jar</goal> </goals> </execution> </executions> </plugin>
Pour résoudre ce problème, trouvez partout où vous avez utilisé maven-source-plugin et assurez-vous que vous utilisez les attach-sources "id" de manière à ce qu'elles soient identiques au profil de version. Ensuite, ces sections seront fusionnées.
Selon les meilleures pratiques, pour obtenir une cohérence, vous devez le configurer dans le POM racine de votre projet dans build> pluginManagement etNOTdans vos poms enfants. Dans le pom enfant, vous indiquez simplement dans build> plugins que vous souhaitez utiliser maven-source-plugin mais vous ne fournissez aucune exécution.
Dans la salle pom.xml:
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.Apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<!-- This id must match the -Prelease-profile id value or else sources will be "uploaded" twice, which causes Nexus to fail -->
<id>attach-sources</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
Dans l'enfant pom.xml:
<build>
<plugins>
<plugin>
<groupId>org.Apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
</plugin>
</plugins>
</build>
Je sais que cette question est ancienne, mais que c’était le hit n ° 1 de Google aujourd’hui, je vais donc ajouter ma réponse appropriée aux versions récentes de maven 3.
Le symptôme est que les sources et les fichiers jar javadoc sont déployés deux fois lors de la compilation d’une version avec certaines versions de maven 3. Si vous utilisez maven pour déployer vos artefacts dans un référentiel Sonatype Nexus qui permet uniquement de télécharger un artefact de version comportement totalement raisonnable), la construction échoue lorsque la deuxième tentative de téléchargement est rejetée. Argh!
Les versions 3.2.3 à 3.3.9 de Maven comportent des bogues - voir https://issues.Apache.org/jira/browse/MNG-5868 et https://issues.Apache.org/jira/browse/MNG-5939 . Ces versions génèrent et déploient deux fois les sources et les fichiers javadoc lors de la publication.
Si je lis correctement le suivi des problèmes Maven, ces correctifs ne sont pas programmés pour le moment de la rédaction de cet article (la version 3.4.0 gravée les affectait probablement).
Au lieu d'un tweak complexe à mon pom, ma solution de contournement simple était de retomber sur Maven version 3.2.1.
Juste après avoir rencontré le même problème, je l'ai analysé un peu. mvn release:perform évalue le fichier release.properties, puis extrait la balise dans un répertoire temporaire et y appelle quelque chose comme
/usr/bin/mvn -D maven.repo.local=... -s /tmp/release-settings5747060794.xml
-D performRelease=true -P set-envs,maven,set-envs deploy
J'ai essayé de reproduire ceci - extrait manuellement la balise produite par release:prepare et invoqué ceci:
mvn -D performRelease=true -P set-envs,maven,set-envs deploy
J'ai eu le même résultat: il essayait de télécharger le fichier -sources.jar deux fois.
Comme indiqué par qualidafial dans un commentaire, définir performRelease=false omet à la place l’une des deux pièces jointes du même fichier.
Je ne sais pas vraiment comment le plugin deploy (ni aucun autre plugin) utilise cette propriété.
Nous pouvons fournir ce paramètre en tant que configuration au plugin maven-relase:
<build>
<plugins>
<plugin>
<groupId>org.Apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<useReleaseProfile>false</useReleaseProfile>
</configuration>
</plugin>
</plugins>
</build>
J'ai maintenant ajouté la ligne <useReleaseProfile>false</useReleaseProfile> à tous les POM, et il semble que la libération fonctionne maintenant sans message d'erreur.
Je suis aux prises avec ce problème depuis un certain temps et j'ai finalement réussi à le résoudre dans notre infrastructure. Les réponses ici ne m'ont pas aidé, car nous n'avions pas plusieurs exécutions des objectifs du plugin source et la configuration nous semblait correcte.
Ce que nous avons manqué, c'est de lier l'exécution du plugin source à une phase. L'extension de l'exemple de Bae, incluant la ligne <phase> install </ phase> à l'exécution, a résolu le problème pour nous:
<plugin>
<artifactId>maven-source-plugin</artifactId>
<version>2.0.4</version>
<executions>
<execution>
<id>attach-sources</id>
<phase>install</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
Je soupçonne que la solution réside dans cette réponse ici ; différents plugins semblent invoquer le but jar/l'exécution attach-sources. En liant notre exécution à une certaine phase, nous forçons notre plugin uniquement à être exécuté dans cette phase.
Cela m'arrivait quand je courais
mvn install deploy
J'ai évité le problème en courant
mvn deploy
(ce qui implique l'installation). Dans mon cas, un seul artefact avait été tenté d'être téléversé deux fois, il s'agissait d'un artefact secondaire (maven-jar-plugin était configuré pour créer un fichier jar secondaire en plus de celui généré par l'exécution de default-jar).
Je ne pense pas que le problème soit dans le plug-in de publication, je pense que vous avez attaché le xxx-sources.jar à deux reprises - c'est pourquoi le téléchargement en double. Pourquoi y at-il une pièce jointe en double est difficile à dire sans voir le POM. Essayez d'exécuter mvn -X et de consulter le journal pour savoir qui attache xxx-source.jar une autre fois.
Dans tous les cas, une bonne solution de contournement sur Nexus consisterait à créer un référentiel de stockage intermédiaire dans lequel vous pourrez télécharger des versions plusieurs fois. Lorsque tout est prêt, il vous suffit de fermer/promouvoir le référentiel de stockage intermédiaire. Consultez le fichier Sonatype OSS setup pour un exemple.
FWIW cette question cassait notre construction depuis un moment et la réponse n’était rien de ce qui précède… .. À la place, j’avais bêtement réglé appendAssemblyId apparemment inoffensif sur false dans un plugin maven-Assembly pour un artefact attaché ( lu déployé, publié) avec notre principal artefact. Par exemple.:
<execution>
<id>ci-groovy-distrib</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<descriptorRefs>
<descriptorRef>my-extra-Assembly</descriptorRef>
</descriptorRefs>
<!-- This is the BUG: the assemblyID MUST be appended
because it is the classifier that distinguishes
this attached artifact from the main one!
-->
<appendAssemblyId>false</appendAssemblyId>
<!-- NOTE: Changes the name of the Zip in the build target directory
but NOT the artifact that gets installed, deployed, releaseed -->
<finalName>my-extra-Assembly-${project.version}</finalName>
</configuration>
</execution>
En résumé:
le plug-in Assembly utilise l'assemblyId en tant que classifieur pour l'artefact, d'où une partie essentielle de ses coordonnées GAV uniques en termes maven (en réalité, il s'agit plus des coordonnées GAVC - C est le classifieur).
le nom du fichier installé, déployé ou publié est en fait construit à partir de ces coordonnées. Il _ {n'est pas le même que le nom de fichier que vous voyez dans votre répertoire cible} _. C'est pourquoi votre version locale semble bonne, mais votre publication échouera.
L'élément stupide détermine uniquement le nom de l'artefact de construction local et ne joue aucun rôle dans le reste. C'est un rouge-hareng complet.
Résumé du résumé:L'erreur 400 de Nexus était due au fait que notre artefact attaché supplémentaire était en cours de téléchargement par-dessus l'artefact principal, car il portait le même nom que l'artefact principal. avait les mêmes coordonnées GAVC que l'artefact principal, car j'avais supprimé la seule coordonnée distinctive: le classificateur dérivé automatiquement de l'assemblyId.
L'enquête visant à découvrir qu'il s'agissait d'un chemin long et tortueux a été corrigée depuis le début de la documentation de maven-Assembly:
appendAssemblyId
booléen
Définissez la valeur sur false pour exclure l'ID d'assembly à partir du nom final de l’Assemblée et pour créer l’Assemblée résultante artefacts sans classificateur. En tant que tel, un artefact Assembly ayant le même format Que l'emballage du projet Maven actuel remplacera Le fichier correspondant à cet artefact de projet principal.
- La valeur par défaut est: true.
- La propriété utilisateur est: Assembly.appendAssemblyId.
De http://maven.Apache.org/plugins/maven-Assembly-plugin/single-mojo.html#attach
Le plus audacieux est à moi. Les docs devraient avoir un gros avertissement clignotant ici: "Définissez ceci sur false et abandonnez tout espoir"
Cette réponse m'a aidé à résoudre un problème différent maven-Assembly-plugin: Comment utiliser appendAssemblyId L'explication fournie par tunaki m'a vraiment aidé.
J'ai eu le même problème. Fondamentalement, le message d'erreur est émis lorsqu'un artefact est envoyé deux fois à Nexus. Cela peut concerner deux fois le même référentiel Nexus ou même plusieurs référentiels au sein du même Nexus.
Cependant, les raisons d'une telle mauvaise configuration peuvent varier. Dans mon cas, les artefacts ont été téléchargés correctement au cours d'une étape de construction de déploiement en mode minimal mvn dans Jenkins, mais ont ensuite échoué lors d'une tentative de déploiement. Ce second déploiement avait été configuré dans une étape de post-génération de Jenkins "Publier des artefacts dans le référentiel Maven".
Les plugins Maven dans les poms parents et enfants ne doivent pas être exécutés. Conformément à la convention standard, définissez tous les plugins avec exécution/objectifs dans pom parent dans la section de gestion des plugins. Child pom ne doit pas redéfinir les détails ci-dessus, mais mentionner uniquement le plug-in (avec artifactId et version) à exécuter.
J'ai eu un problème similaire avec maven-Assembly-plugin avec parent pom comme ci-dessous:
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-Assembly-plugin</artifactId>
<version>2.6</version>
<configuration>
<descriptors>
<descriptor>src/Assembly/assembly.xml</descriptor>
</descriptors>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
Et Child pom avait maven-Assembly-plugin comme ci-dessous:
<build>
<plugins>
<plugin>
<artifactId>maven-Assembly-plugin</artifactId>
<version>2.2-beta-5</version>
<configuration>
<finalName>xyz</finalName>
<descriptors>
<descriptor>src/Assembly/assembly.xml</descriptor>
</descriptors>
</configuration>
<executions>
<execution>
<id>xyz-distribution</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
La suppression du <executions> du pom enfant a corrigé le problème . Le pom effectif avait 2 exécutions exécutées, ce qui entraînait l'installation dupliquée dans le dépôt Nexus.