Le plugin Maven release échoue: les artefacts source se déploient deux fois

Question

Nous utilisons le plugin maven release sur hudson et essayons d'automatiser le processus de release. La libération: préparer fonctionne bien. Lorsque nous essayons de faire la release: perform, elle échoue car elle essaie de télécharger deux fois un artefact source dans le référentiel.

choses que j'ai essayé,

1. enlever le profil qui inclut le plug-in source maven de la super pom (ne fonctionne pas)
2. spécifiant les objectifs sur hudson pour la libération comme -P! Attachement source release: préparer la version: perform. Ce que je pensais exclut l'exécution du plugin source. (n'a pas fonctionné).
3. essayé de spécifier la phase de plug-in à une phase inexistante dans le super pom. (N'a pas fonctionné)
4. essayé de spécifier la configuration du plugin, pourReleaseProfile comme faux. (devinez quoi ?? ne fonctionnait pas trop)

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 concernant ceci sera vraiment appréciée.

Answer 1

Essayez d'exécuter mvn -Prelease-profile help:effective-pom. Vous constaterez que vous disposez de deux sections d'exécution pour maven-source-plugin

La sortie ressemblera à quelque chose comme 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 le "id" attach-sources de sorte qu'il est le même que le profil de libération. Ensuite, ces sections seront fusionnées. La meilleure pratique indique que pour être cohérent, vous devez le configurer dans le POM racine de votre projet dans build> pluginManagement et NOT dans vos poms enfants. Dans le pom enfant, il suffit de spécifier dans build> plugins que vous voulez 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> 

Chez l'enfant pom.xml:

<build> 
    <plugins> 
    <plugin> 
     <groupId>org.apache.maven.plugins</groupId> 
     <artifactId>maven-source-plugin</artifactId> 
    </plugin> 
    </plugins> 
</build> 

Answer 2

Je ne pense pas que le problème est dans le plugin de version, je pense que vous avez le xxx-sources.jar attaché deux fois - c'est pourquoi le téléchargement en double. Pourquoi est-il un attachement en double est difficile à dire sans voir le POM. Essayez d'exécuter mvn -X et de vérifier le journal pour savoir qui joint xxx-source.jar une autre fois. Dans tous les cas, une bonne solution de contournement sur Nexus consisterait à disposer d'un référentiel de transfert dans lequel vous pourrez télécharger des versions plusieurs fois. Lorsque tout sera prêt, vous devrez simplement fermer/promouvoir le dépôt intermédiaire. Vérifiez le Sonatype OSS setup pour un exemple.

Answer 3

J'ai configuré le plug-in de libération maven avec releaseProfile = false et n'exécute pas le profil d'artefacts source. Lequel a fait l'affaire.

<build> 
      <plugins> 
       <plugin> 
        <groupId>org.apache.maven.plugins</groupId> 
        <artifactId>maven-release-plugin</artifactId> 
        <version>2.1</version> 
        <configuration> 
          <arguments>-P!source-artifacts</arguments> 
          <useReleaseProfile>false</useReleaseProfile> 
          <goals>-Dmaven.test.skip=true deploy</goals> 
        </configuration>  
       </plugin> 
      </plugins> 
     </build> 

Answer 4

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 vérifie l'étiquette dans un répertoire temporaire et 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 ce - vérifié manuellement l'étiquette produit par release:prepare et invoqué ceci:

mvn -D performRelease=true -P set-envs,maven,set-envs deploy 

J'ai obtenu le même résultat: Il essayait de télécharger deux fois le fichier -sources.jar.

Comme indiqué par qualidafial dans un commentaire, le paramètre performRelease=false omet à la place une des deux pièces jointes du même fichier.

Je n'ai pas vraiment une idée de comment le deploy plugin (ou tout autre plugin) utilise cette propriété.

Nous pouvons fournir ce paramètre comme une configuration à l'maven-relase-plugin:

<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> 

I maintenant ajouté la ligne <useReleaseProfile>false</useReleaseProfile> à tous les POMs, et il semble que la libération fonctionne maintenant sans message d'erreur.

Answer 5

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 être deux fois le même référentiel Nexus ou même à travers différents référentiels dans le 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 lors d'une étape de génération de déploiement clean mvn dans Jenkins, mais ont échoué lorsqu'un second déploiement a été tenté. Ce second déploiement a été configuré dans une étape de construction de publication Jenkins "Publier des artefacts dans le référentiel Maven".

Answer 6

J'ai lutté avec ce problème pendant un certain temps et ai finalement été capable de 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 a semblé bien.

Ce que nous avons manqué était de lier l'exécution du plugin source à une phase. L'extension de l'exemple par Bae, y compris la ligne < de phase> install < phase /> à l'exécution tranché la question 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 here; différents plugins semblent invoquer l'objectif jar/l'exécution attach-sources. En liant notre exécution à une certaine phase, nous forçons notre plugin à s'exécuter dans cette phase.

Answer 7

Les plugins Maven dans les poms parents et enfants ne doivent pas avoir d'exécution. Conformément à la convention standard, définissez tout plugin avec exécution/objectifs dans la section pom parent dans la gestion des plugins. Pom enfant ne doit pas redéfinir les détails ci-dessus, mais mentionne seulement le plugin (avec artefact et la version) qui doit être exécuté.

J'ai eu problème similaire avec maven-assembly-plugin avec pom parent 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 pom enfant 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> 

Retrait de la <executions> de l'enfant pom a rectifié le problème. Le pom effectif a eu 2 exécutions effectuées causant l'installation en double à repo Nexus.

Answer 8

Je sais que cette question est vieux, mais il était google a frappé # 1 aujourd'hui, donc je vais ajouter ma réponse appropriée pour les versions récentes de Maven 3.

Le symptôme est que les sources et les jars de Javadoc sont déployés deux fois lorsque vous faites une version créée 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 une fois (ce qui est un comportement tout à fait raisonnable), la construction échoue lors du second téléchargement tentative est rejetée. Argh! Les versions Maven 3.2.3 à 3.3.9 ont 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 des sources et des javadocs deux fois lors d'une publication.

Si je lis correctement le programme de suivi des problèmes de Maven, ces correctifs ne sont pas planifiés pour correction à ce jour (la version 3.4.0 gravée les a probablement affectés). Au lieu d'un ajustement complexe à mon pom, ma solution de contournement simple était de revenir à la version 3.2.1 de Maven.

Answer 9

FWIW ce problème brisait notre construction depuis un moment et la réponse n'était pas du tout-dessus. Au lieu de cela j'avais bêtement mis l'appendAssemblyId apparemment inoffensif à false dans un maven-assembly-plugin pour un artefact qui est attaché (lu déployé, libéré) avec notre artefact principal. 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é:

1. le plugin d'assemblage utilise le assemblyId comme le classificateur pour l'artefact, donc une partie essentielle est GAV unique de coordonnées en termes de Maven (en fait il est plus comme les coordonnées GAVC - C est le classificateur).

2. le nom du fichier installé, déployé, ou libéré 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 build local a l'air bien, mais votre version échouera. L'élément stupide ne détermine que le nom de l'artefact de construction local et ne joue aucun rôle dans le reste de celui-ci. C'est un hareng rouge complet.

Résumé du résumé: L'erreur 400 de Nexus était parce que notre artefact d'attaché était transféré sur le dessus de l'artefact principal, car il avait le même nom que l'artefact principal, parce qu'il avait les mêmes coordonnées GAVC que l'artefact principal, car j'ai supprimé la seule coordonnée distinctive: le classificateur dérivé automatiquement de l'assemblyId.

L'enquête pour trouver ce fut un chemin long et tortueux, la réponse était là tout au long de la documentation pour maven-montage:

appendAssemblyId

• booléenne

• Défini sur false pour exclure l'ID d'assembly à partir du nom final de l'assemblage et pour créer l'ensemble résultant artefacts sans classificateur. En tant que tel, un artefact d'assemblage ayant le même format que l'emballage du projet Maven en cours remplacera le fichier de 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 gras supplémentaire est à moi. Les docs devraient avoir un grand avertissement clignotant ici: "Mettre cela à faux et abandonner tout espoir"

J'ai reçu de l'aide de cette réponse à propos d'un problème différent maven-assembly-plugin: How to use appendAssemblyId L'explication de tunaki m'a vraiment aidé.