Le déploiement du projet Maven lève java.util.zip.ZipException: en-tête LOC non valide (signature incorrecte)

164

J'obtiens l'exception ci-dessous lorsque j'exécute mon mvn install. J'ai même supprimé le référentiel local et exécuté à nouveau en obtenant la même exception.

[ERREUR] Échec de l'exécution de l'objectif org.apache.maven.plugins: maven-ombre-plugin: 2.1: ombre (par défaut) sur le projet cores-batch: Erreur lors de la création du pot ombré: en-tête LOC non valide (signature incorrecte) -> [Aide 1 ]

<?xml version="1.0" encoding="UTF-8"?>
<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-shade-plugin</artifactId>
   <version>2.1</version>
   <configuration>
      <skipTests>true</skipTests>
   </configuration>
   <executions>
      <execution>
         <phase>package</phase>
         <goals>
            <goal>shade</goal>
         </goals>
         <configuration>
            <artifactSet>
               <excludes>
                  <exclude>commons-logging:commons-logging:jar:*</exclude>
               </excludes>
            </artifactSet>
            <filters>
               <filter>
                  <artifact>*:*</artifact>
                  <excludes>
                     <!-- workaround for a spring issues -->
                     <exclude>META-INF/*.SF</exclude>
                     <exclude>META-INF/*.DSA</exclude>
                     <exclude>META-INF/*.RSA</exclude>
                     <!-- don't want to pick up any other log4j.xml -->
                     <exclude>log4j.xml</exclude>
                  </excludes>
               </filter>
            </filters>
            <!-- May be needed to work around another issue in Spring -->
            <transformers>
               <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
                  <resource>META-INF/spring.handlers</resource>
               </transformer>
               <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
                  <resource>META-INF/spring.schemas</resource>
               </transformer>
            </transformers>
         </configuration>
      </execution>
   </executions>
</plugin>

Erreur:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:2.1:shade (default) on project cores-batch: Error creating shaded jar: invalid LOC header (bad signature) -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:2.1:shade (default) on project cores-batch: Error creating shaded jar: invalid LOC header (bad signature)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating shaded jar: invalid LOC header (bad signature)
    at org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:528)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
    ... 19 more
Caused by: java.util.zip.ZipException: invalid LOC header (bad signature)
    at java.util.zip.ZipFile.read(Native Method)
    at java.util.zip.ZipFile.access$1400(ZipFile.java:56)
    at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:679)
    at java.util.zip.ZipFile$ZipFileInflaterInputStream.fill(ZipFile.java:415)
    at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158)
    at java.io.FilterInputStream.read(FilterInputStream.java:107)
    at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:189)
    at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:175)
    at org.apache.maven.plugins.shade.DefaultShader.addResource(DefaultShader.java:427)
    at org.apache.maven.plugins.shade.DefaultShader.shade(DefaultShader.java:186)
    at org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:458)
    ... 21 more
[ERROR] 
[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
maven  jakarta-ee  deployment  jar 
— Karthick
source
1
Création d'un plugin pour ce problème -> github.com/goxr3plus/CorruptedJarsDetector
— GOXR3PLUS
1
@ GOXR3PLUS Il n'y a pas vraiment de code dans ce repo (sauf pour la classe dans le README), encore moins celui d'un plugin Maven. Je pense qu'un plugin maven serait la meilleure solution, en fait - ou juste une extension de l'un des plugins existants qui permettait de faire quelque chose comme un mvn dependencies validateou deux ...
— Marco13
Marco le code du référentiel est celui de la classe lol :)
— GOXR3PLUS

Réponses:

79

Vous devez vérifier quel pot pose problème. Il doit être corrompu. Supprimez ce fichier et exécutez à mvn spring-boot:runnouveau la commande. Il se peut que plusieurs fichiers jar aient été corrompus, donc à chaque fois que vous devez exécuter cette commande pour supprimer ce fichier jar. Dans mon cas, mysql, jackson, aspect jars a été corrompu mvn spring-boot:run3 fois et j'ai compris cela et j'ai supprimé les jars du .m2dossier. Maintenant, le problème est résolu.

— alok
source
218

Le fichier jar est peut-être corrompu. Essayez de supprimer le contenu du dossier suivant:

 C:\Users\[username]\.m2\repository

Ensuite, faites un clic droit sur votre projet, sélectionnez Maven, Update Project, cochez Forcer la mise à jour des snapshots / releases

— Siva Anand
source
4
Cela devrait être marqué comme la solution. Je pense que c'est aussi la solution à plusieurs autres questions connexes qui n'ont pas de réponse. Merci Siva!
— Hack-R
1
très sympa .. après avoir passé 7 heures, j'ai trouvé la solution ... KUDOS pour vous mec ....
— Sufiyan Ansari
4
Cela fonctionne, mais supprimer tout le référentiel local maven n'est pas la meilleure option. Supprimez simplement les fichiers jar associés et cela suffit.
— Levent Divilioglu
2
Vous n'avez pas à supprimer toutes les dépendances, en haut, vous pouvez trouver quelles dépendances ont un mauvais en-tête LOC.
— umar faraz
2
Juste pour noter l'évidence: quand quelqu'un rencontre invalid LOC headerdans Gradle build, vous supprimez simplement le ~/.gradle/cachesdossier (Linux).
— Martin Vseticka
110

Le principal problème est les bocaux corrompus.

Pour trouver celui qui est corrompu, vous devez ajouter un point d' arrêt d'exception Java dans la vue des points d'arrêt d'Eclipse, ou votre IDE préféré, sélectionnez le java.util.zip.ZipException classe et redémarrez l'instance Tomcat.

Lorsque la JVM s'arrête au ZipExceptionpoint d'arrêt, vous devez accéder à JarFile.getManifestFromReference()la trace de la pile et vérifier l'attribut namepour voir le nom du fichier.

Après cela, vous devez supprimer le fichier du système de fichiers, puis faites un clic droit sur votre projet, sélectionnez Maven, Mettre à jour le projet, cochez Forcer la mise à jour des instantanés / versions.

— Matias Sebastiao
source
11
Je pense que cela devrait être la réponse acceptée. Le simple fait de supprimer des centaines de fichiers jar et de les télécharger à nouveau n'est pas une solution efficace.
— Mohsen
11
rm -rf .m2 = effective
— Jeryl Cook
2
Technique de débogage impressionnante là-bas. M'a évité de gaspiller de la bande passante pour télécharger toutes les dépendances ou artefacts. Je vous remercie.
— Thariq Nugrohotomo
3
Grande technique!. Je n'ai pas pu trouver le cadre JarFile, mais je l'ai trouvé ici sous le nom d'expression ZipFile.this.name sur le cadre ZipFile $ ZipFileInputStream.read.
— rlpatrao
2
Un exemple simple de ces pots corrompus: stackoverflow.com/a/46623719/3128926 Il a fallu 2 heures pour comprendre quel est le problème. Btw, il suffit de supprimer uniquement les fichiers jar associés au lieu d'effacer tout le cache local de maven.
— Levent Divilioglu
41

Depuis gsitgithub / find-currupt-jars.txt , la commande suivante répertorie tous les fichiers jar corrompus dans le référentiel:

find  /home/me/.m2/repository/ -name "*jar" | xargs -L 1 zip -T | grep error | grep invalid

Vous pouvez supprimer les fichiers jar corrompus et recompiler le projet.

Exemple de sortie:

warning [/cygdrive/J/repo/net/java/dev/jna/jna/4.1.0/jna-4.1.0.jar]:  98304 extra bytes at beginning or within zipfile
  (attempting to process anyway)
file #1:  bad zipfile offset (local header sig):  98304
  (attempting to re-compensate)
zip error: Zip file invalid, could not spawn unzip, or wrong unzip (original files unmodified)
— Javier
source
1
sudo find ./repository/ -name "*jar" | sudo xargs -L 1 zip -T | grep error | grep invalid me donne xargs: zip: No such file or directory. ceci utilise bash sur ubuntu sur windows, fyi
— liltitus27
1
@ liltitus27 Cette ligne de commande exécute zip -T(teste) sur chaque jar sous repository, puis filtre les jars qui sont des fichiers compressés invalides. Avez-vous la zipcommande disponible?
— Javier
il semble que dans bash, je n'ai pas installé de zip. J'ai cependant trouvé que la commande exacte que vous avez publiée fonctionne à merveille dans cygwin. et aussi, cela a fonctionné pour trouver de mauvais pots, merci!
— liltitus27
2
Tu es le meilleur, MAN!
— Igor Masternoy le
L'idée est de fonctionner zip -Tsur chaque pot stocké sous .m2/repository. Sous Windows, vous pouvez l'exécuter sur Cygwin ( /cygdrive/C/Users/torno/.m2/repository) comme je l'ai fait, et je pense que vous pouvez également l'exécuter avec Bash sur Windows 10 ( /mnt/c/Users/torno/.m2/repository). Je n'ai pas étudié comment écrire un script équivalent avec PowerShell, et je pense que cela ne devrait pas être possible avec une invite cmd.
— Javier
11

Je voudrais donner ma pratique.

Utilisez votre IDE préféré, prenez par exemple eclipse ici:

  1. Trouvez un emplacement approprié dans la pile d'exceptions
  2. Définir un point d'arrêt conditionnel
  3. Déboguer
  4. Il imprimera le pot corrompu avant l'exception

entrez la description de l'image ici

— samm
source
1
C'est une bien meilleure solution que d'effacer tout le référentiel m2, qui dans mon cas prendrait des siècles à télécharger à nouveau.
— Martin Cassidy
5

La solution pour moi était de courir mvnavec -X:

$ mvn package -X

Ensuite, regardez en arrière dans la sortie jusqu'à ce que vous voyiez l'échec, puis continuez jusqu'à ce que vous voyiez le dernier fichier jar que mvn a essayé de traiter:

...
... <<output ommitted>>
...
[DEBUG] Processing JAR /Users/snowch/.m2/repository/org/eclipse/jetty/jetty-server/9.2.15.v20160210/jetty-server-9.2.15.v20160210.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.607 s
[INFO] Finished at: 2017-10-04T14:30:13+01:00
[INFO] Final Memory: 23M/370M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:3.1.0:shade (default) on project kafka-connect-on-cloud-foundry: Error creating shaded jar: invalid LOC header (bad signature) -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:3.1.0:shade (default) on project kafka-connect-on-cloud-foundry: Error creating shaded jar: invalid LOC header (bad signature)

Regardez le dernier jar avant qu'il échoue et supprimez-le du référentiel local, c'est-à-dire

$ rm -rf /Users/snowch/.m2/repository/org/eclipse/jetty/jetty-server/9.2.15.v20160210/
— Chris Snow
source
2

On dirait un problème de configuration pour le compilateur maven dans votre fichier pom. La source et la cible Java de la version par défaut sont 1.5, même JDK utilisé a une version supérieure.

Pour résoudre le problème, ajoutez la section de configuration du plugin maven compiler avec une version Java supérieure, exemple:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.6.1</version>
  <configuration>
    <source>1.6</source>
    <target>1.6</target>
  </configuration>
</plugin>

Pour plus d'informations, consultez ces liens:

compilateur maven

rapport d'erreur

— récolte
source
1

Cette réponse n'est pas pour les administrateurs de DevOps / système, mais pour ceux qui utilisent l'EDI comme Eclipse et font face à des invalid LOC header (bad signature)problèmes.

Vous pouvez forcer la mise à jour des dépendances maven, comme suit:

entrez la description de l'image ici

entrez la description de l'image ici

— Vishrant
source
1

Voici un petit détecteur écrit en Java, il suffit de copier et d'exécuter :) 

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.util.ArrayList;
import java.util.List;
import java.util.jar.JarFile;
import java.util.stream.Collectors;

public class JarValidator {

    public static void main(String[] args) throws IOException {
        Path repositoryPath = Paths.get("C:\\Users\\goxr3plus\\.m2");

        // Check if the main Repository Exists
        if (Files.exists(repositoryPath)) {

            // Create a class instance
            JarValidator jv = new JarValidator();

            List<String> jarReport = new ArrayList<>();
            jarReport.add("Repository to process: " + repositoryPath.toString());

            // Get all the directory files
            List<Path> jarFiles = jv.getFiles(repositoryPath, ".jar");
            jarReport.add("Number of jars to process: " + jarFiles.size());
            jarReport.addAll(jv.openJars(jarFiles, true));

            // Print the report
            jarReport.stream().forEach(System.out::println);

        } else {
            System.out.println("Repository path " + repositoryPath + " does not exist.");
        }
    }

    /**
     * Get all the files from the given directory matching the specified extension
     * 
     * @param filePath      Absolute File Path
     * @param fileExtension File extension
     * @return A list of all the files contained in the directory
     * @throws IOException
     */
    private List<Path> getFiles(Path filePath, String fileExtension) throws IOException {
        return Files.walk(filePath).filter(p -> p.toString().endsWith(fileExtension)).collect(Collectors.toList());
    }

    /**
     * Try to open all the jar files
     * 
     * @param jarFiles
     * @return A List of Messages for Corrupted Jars
     */
    private List<String> openJars(List<Path> jarFiles, boolean showOkayJars) {
        int[] badJars = { 0 };
        List<String> messages = new ArrayList<>();

        // For Each Jar
        jarFiles.forEach(path -> {

            try (JarFile file = new JarFile(path.toFile())) {
                if (showOkayJars)
                    messages.add("OK : " + path.toString());
            } catch (IOException ex) {
                messages.add(path.toAbsolutePath() + " threw exception: " + ex.toString());
                badJars[0]++;
            }
        });

        messages.add("Total bad jars = " + badJars[0]);
        return messages;
    }

}

Production

Repository to process: C:\Users\goxr3plus\.m2
Number of jars to process: 4920
C:\Users\goxr3plus\.m2\repository\bouncycastle\isoparser-1.1.18.jar threw exception: java.util.zip.ZipException: zip END header not found
Total bad jars = 1
BUILD SUCCESSFUL (total time: 2 seconds)
— GOXR3PLUS
source
1

Nous pouvons forcer la validation de la somme de contrôle dans maven avec au moins deux options:

1.Ajout du --strict-checksums à notre commande maven.

2.Ajout de la configuration suivante à notre fichier de paramètres maven: 

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                          https://maven.apache.org/xsd/settings-1.0.0.xsd">
    <!--...-->
    <profiles>
        <profile>
            <!--...-->
            <repositories>
                <repository>
                    <id>codehausSnapshots</id>
                    <name>Codehaus Snapshots</name>
                    <releases>
                        <enabled>false</enabled>
                        <updatePolicy>always</updatePolicy>
                        <checksumPolicy>fail</checksumPolicy>
                    </releases>
                    <snapshots>
                        <enabled>true</enabled>
                        <updatePolicy>never</updatePolicy>
                        <checksumPolicy>fail</checksumPolicy>
                    </snapshots>
                    <url>
                        <!--...-->
                    </url>
                </repository>
            </repositories>
            <pluginRepositories>
                <!--...-->
            </pluginRepositories>
            <!--...-->
        </profile>
    </profiles>
    <!--...-->
</settings>

Plus de détails dans cet article: https://dzone.com/articles/maven-artifact-checksums-what

— SHoko
source
0

Au-delà de la suppression du .m2 / référentiel, supprimez l'application du serveur, exécutez le serveur (sans applications), arrêtez-le et ajoutez à nouveau l'application. Maintenant, il est censé fonctionner. Pour une raison quelconque, le simple nettoyage des dossiers du serveur à partir de l'interface n'a pas le même effet.

— Alex
source
0

J'étais confronté à ce problème lors du déploiement de mon oreille sur mon instance weblogic locale. La suppression du référentiel local et la construction de l'oreille ont à nouveau résolu le problème pour moi.

— SMT_Dev
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.