J'ai un fichier pom.xml et un fichier assembly-descriptor.xml séparé. Le résultat final est un fichier tar.gz qui contient ma webapp tomcat et certains fichiers jar. Lorsque je compile ceci sur ma boîte de dev locale (Mac OS 10.7 et Maven 3.0.3) le tar.gz qui en résulte contient un fichier jar valide. Lorsque la construction s'exécute sur notre boîte de construction (Jenkins sur le serveur Linux/Maven 3.0.3) et est déployée sur le serveur de production, le fichier JAR est presque deux fois la taille qu'il devrait être et est corrompu. Je peux reproduire le problème de doublage/corruption localement quand je change la version du plugin d'assemblage de maven en 2.3 ou 2.4. Lorsque je le mets à 2.1 ou 2.2 ou pas de version (par défaut à 2.2 beta 5) cela fonctionne localement. Mais peu importe la version que je choisis, la construction échoue pendant l'étape tar gz sur la boîte de construction. (. Java version locale = 1.6.0_37 et 1.6.0_34 système de compilation est mais je ne pense pas que cet écart est à blâmer)
Voici mon pom.xml:Le fichier tar gz contient des fichiers jar corrompus après la génération de Maven
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.3</version>
<configuration>
<encoding>UTF-8</encoding>
<finalName>${project.build.finalName}_${project.version}</finalName>
<descriptors>
<descriptor>src/main/assembly/assembly-descriptor.xml</descriptor>
</descriptors>
<attach>true</attach>
<appendAssemblyId>false</appendAssemblyId>
</configuration>
<executions>
<execution>
<id>package-tar-gz</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>...
` est ici l'assemblée descripteur (assemblage descriptor.xml):
<?xml version="1.0" encoding="UTF-8"?>
<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd">
<id>bin</id>
<includeBaseDirectory>false</includeBaseDirectory>
<formats>
<format>tar.gz</format>
</formats>
<fileSets>
<fileSet>
<directory>${project.basedir}/src/main/tomcat</directory>
<filtered>true</filtered>
<excludes>
<exclude>**/*.war</exclude>
</excludes>
<outputDirectory>/</outputDirectory>
</fileSet>
</fileSets>
</assembly>
Enfin, une autre différence entre la construction locale et la construction de la production est que la construction de la production utilise un référentiel local et mon construction locale ne fonctionne pas. Je n'y ai pas prêté beaucoup d'attention car je suis capable de reproduire localement le problème de doublage/corruption de fichier jar (c'est-à-dire sans problème de repo local).
Pouvez-vous préciser ce que ** Mais peu importe quelle version je choisis, la génération échoue pendant la gz tar ** moyens? Pouvez-vous montrer la sortie du journal? – khmarbaise
Désolé, c'était trompeur. La construction est "réussie" dans tous les cas, toutes les versions. Ce que je voulais dire, c'est que les fichiers jar sont corrompus pendant la construction officielle, peu importe la version du plugin d'assemblage que je choisis. Ce qui est étrange, c'est que je peux reproduire le problème sur ma version locale en utilisant les versions 2.3 et 2.4 du plugin d'assemblage. J'ai lu un autre article sur ce site qui indiquait que vous pouviez spécifier de ne pas compresser les fichiers jar pendant l'assemblage, mais l'élément 'compress' n'était pas compris. – user1814008
Solution: cela a été corrigé pour moi en m'assurant que la version du plugin d'assemblage maven (2.4) était alignée/compatible avec la version du schéma d'assemblage (1.1.2). Aussi, et plus important encore, la définition de l'ensemble de fichiers était funky. Une fois que je l'ai réécrit et l'ai simplifié, les choses ont bien fonctionné. En particulier, il y avait une étrange définition pour filtrer les fichiers de guerre pour un répertoire puis une deuxième définition pour inclure les fichiers de guerre. Je pense que ce combo n'était pas bien formaté et fonctionnait sur une plate-forme et pas une autre. – user1814008