Beim Bereitstellen des Maven-Projekts wird eine java.util.zip.ZipException ausgelöst: Ungültiger LOC-Header (falsche Signatur)

164

Ich erhalte die folgende Ausnahme, wenn ich meine ausführe mvn install. Ich habe sogar das lokale Repository gelöscht und es erneut ausgeführt, wobei dieselbe Ausnahme aufgetreten ist.

[FEHLER] Fehler beim Ausführen des Ziels org.apache.maven.plugins: maven-shadow-plugin: 2.1: shadow (Standard) für Projektkerne-Batch: Fehler beim Erstellen des schattierten JAR: ungültiger LOC-Header (falsche Signatur) -> [Hilfe 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>

Error:

[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
quelle
1
Ein Plugin für dieses Problem erstellt -> github.com/goxr3plus/CorruptedJarsDetector
GOXR3PLUS
1
@ GOXR3PLUS Es gibt nicht wirklich Code in diesem Repo (außer der Klasse in der README), noch weniger den eines Maven-Plugins. Ich denke, dass ein Maven-Plugin tatsächlich die beste Lösung wäre - oder nur eine Erweiterung eines der vorhandenen Plugins, die so etwas wie mvn dependencies validate... oder so erlaubten ...
Marco13
Marco der Code für das Repository ist der in der Klasse lol :)
GOXR3PLUS

Antworten:

79

Sie müssen überprüfen, welches Glas ein Problem darstellt. Es muss beschädigt sein. Löschen Sie das Glas und führen Sie den mvn spring-boot:runBefehl erneut aus. Möglicherweise ist mehr als ein Glas beschädigt, sodass Sie jedes Mal, wenn Sie diesen Befehl ausführen müssen, um dieses Glas zu löschen. In meinem Fall war MySQL, Jackson, Aspekt Jars mvn spring-boot:runBefehl 3 Mal beschädigt und ich habe dies herausgefunden und die Jars aus dem .m2Ordner gelöscht . Jetzt ist das Problem behoben.

alok
quelle
218

Die JAR-Datei ist möglicherweise beschädigt. Versuchen Sie, den Inhalt des folgenden Ordners zu entfernen:

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

Klicken Sie dann mit der rechten Maustaste auf Ihr Projekt, wählen Sie Maven, Projekt aktualisieren und aktivieren Sie die Option Aktualisierung von Snapshots / Releases erzwingen.

Siva Anand
quelle
4
Dies sollte als Lösung markiert werden. Ich glaube, es ist auch die Lösung für einige andere verwandte Fragen, die keine Antworten haben. Danke Siva!
Hack-R
1
sehr schön .. nachdem ich 7 Stunden verbracht hatte, fand ich die Lösung heraus ... KUDOS für Sie Mann ....
Sufiyan Ansari
4
Dies funktioniert, aber das Löschen des gesamten lokalen Maven-Repositorys ist nicht die beste Option. Löschen Sie einfach die zugehörigen JAR-Dateien und das reicht.
Levent Divilioglu
2
Sie müssen nicht alle Abhängigkeiten löschen. Oben finden Sie, welche Abhängigkeiten einen schlechten LOC-Header haben.
Umar Faraz
2
Nur um das Offensichtliche zu beachten: Wenn jemand invalid LOC headerin Gradle Build auf etwas stößt , löschen Sie einfach den ~/.gradle/cachesOrdner (Linux).
Martin Vseticka
110

Das Hauptproblem sind beschädigte Gläser.

Um den beschädigten zu finden, müssen Sie einen Java-Ausnahme-Haltepunkt in der Haltepunktansicht von Eclipse oder Ihre bevorzugte IDE hinzufügen , die java.util.zip.ZipExceptionKlasse auswählen und die Tomcat-Instanz neu starten.

Wenn die JVM am ZipExceptionHaltepunkt angehalten wird, müssen Sie JarFile.getManifestFromReference()in der Stapelverfolgung nachsehen und das Attribut überprüfen name, um den Dateinamen anzuzeigen.

Danach sollten Sie die Datei aus dem Dateisystem löschen und dann mit der rechten Maustaste auf Ihr Projekt klicken, Maven auswählen, Projekt aktualisieren und die Option Aktualisierung von Snapshots / Releases erzwingen aktivieren.

Matias Sebastiao
quelle
11
Ich glaube, das sollte die akzeptierte Antwort sein. Das einfache Entfernen von Hunderten von JAR-Dateien und das erneute Herunterladen ist keine effiziente Lösung.
Mohsen
11
rm -rf .m2 = wirksam
Jeryl Cook
2
Tolle Debugging-Technik. Ersparte mir die Verschwendung von Bandbreite, um die gesamten Abhängigkeiten oder Artefakte herunterzuladen. Danke dir.
Thariq Nugrohotomo
3
Tolle Technik! Ich konnte den JarFile-Frame nicht finden, aber hier wurde er als Ausdruck ZipFile.this.name im ZipFile $ ZipFileInputStream.read-Frame gefunden.
Rlpatrao
2
Ein einfaches Beispiel für diese beschädigten Gläser: stackoverflow.com/a/46623719/3128926 Es dauerte 2 Stunden, um das Problem zu verstehen. Übrigens reicht es aus, nur verwandte JAR-Dateien zu entfernen, anstatt den gesamten lokalen Maven-Cache zu leeren.
Levent Divilioglu
41

In der Datei gsitgithub / find-currupt-jars.txt listet der folgende Befehl alle beschädigten JAR-Dateien im Repository auf:

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

Sie können die beschädigten JAR-Dateien löschen und das Projekt neu kompilieren.

Beispielausgabe:

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
quelle
1
sudo find ./repository/ -name "*jar" | sudo xargs -L 1 zip -T | grep error | grep invalid gibt mir xargs: zip: No such file or directory. Dies ist Bash auf Ubuntu auf Windows, fyi
liltitus27
1
@ liltitus27 Diese Befehlszeile wird zip -Tfür jedes Glas unter ausgeführt (getestet) und filtert repositorydann, welche Gläser ungültige komprimierte Dateien sind. Haben Sie zipBefehl zur Verfügung?
Javier
Es scheint, dass ich in Bash keine Zip installiert habe. Ich habe jedoch festgestellt, dass der genaue Befehl, den Sie gepostet haben, in Cygwin wunderbar funktioniert. und es hat auch funktioniert, schlechte Gläser zu finden, danke!
Liltitus27
2
Du bist der Beste, MAN!
Igor Masternoy
Die Idee ist, zip -Tauf jedem Glas zu laufen, das unter gespeichert ist .m2/repository. In Windows können Sie es /cygdrive/C/Users/torno/.m2/repositorywie ich unter Cygwin ( ) ausführen , und ich denke, Sie können es auch mit Bash unter Windows 10 ( /mnt/c/Users/torno/.m2/repository) ausführen . Ich habe nicht untersucht, wie ein gleichwertiges Skript mit PowerShell geschrieben werden kann, und ich denke, dass dies mit einer cmd-Eingabeaufforderung nicht möglich sein sollte.
Javier
11

Ich möchte meine Praxis geben.

Verwenden Sie Ihre bevorzugte IDE, nehmen Sie zum Beispiel Eclipse hier:

  1. Suchen Sie einen geeigneten Speicherort im Ausnahmestapel
  2. Bedingten Haltepunkt setzen
  3. Debuggen Sie es
  4. Das beschädigte Glas wird vor der Ausnahme gedruckt

Geben Sie hier die Bildbeschreibung ein

samm
quelle
1
Dies ist eine weitaus bessere Lösung als das Löschen des gesamten m2-Repositorys, dessen erneuter Download in meinem Fall ewig dauern würde.
Martin Cassidy
5

Die Lösung für mich war zu laufen mvnmit -X:

$ mvn package -X

Schauen Sie dann rückwärts durch die Ausgabe, bis Sie den Fehler sehen, und fahren Sie fort, bis Sie die letzte JAR-Datei sehen, die mvn zu verarbeiten versucht hat:

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

Schauen Sie sich das letzte Glas an, bevor es fehlgeschlagen ist, und entfernen Sie es aus dem lokalen Repository, d. H.

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

Sieht nach einem Konfigurationsproblem für den Maven-Compiler in Ihrer POM-Datei aus. Die Standardversion von Java Source und Target ist 1.5, selbst das verwendete JDK hat eine höhere Version.

Fügen Sie zur Behebung einen Konfigurationsabschnitt für das Maven-Compiler-Plugin mit einer höheren Java-Version hinzu. Beispiel:

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

Weitere Informationen finden Sie unter folgenden Links:

Maven Compiler

Fehlerbericht

harvyS
quelle
1

Diese Antwort ist nicht für DevOps / Systemadministratoren gedacht, sondern für diejenigen, die IDE wie Eclipse verwenden und Probleme haben invalid LOC header (bad signature).

Sie können die Aktualisierung der Maven-Abhängigkeiten wie folgt erzwingen:

Geben Sie hier die Bildbeschreibung ein

Geben Sie hier die Bildbeschreibung ein

Vishrant
quelle
1

Hier ist ein kleiner Detektor in Java geschrieben, einfach kopieren und ausführen :) 

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

}

Ausgabe

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

Wir können die Prüfsummenvalidierung in maven mit mindestens zwei Optionen erzwingen:

1. Hinzufügen des Befehls --strict-checksumszu unserem Maven-Befehl.

2. Hinzufügen der folgenden Konfiguration zu unserer Maven-Einstellungsdatei: 

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

Weitere Details in diesem Beitrag: https://dzone.com/articles/maven-artifact-checksums-what

SHoko
quelle
0

Entfernen Sie über das Entfernen von .m2 / repository hinaus die Anwendung vom Server, führen Sie den Server (ohne Anwendungen) aus, stoppen Sie ihn und fügen Sie die Anwendung erneut hinzu. Jetzt soll es funktionieren. Aus irgendeinem Grund hat das Bereinigen von Serverordnern von der Benutzeroberfläche nicht den gleichen Effekt.

Alex
quelle
0

Ich hatte dieses Problem, als ich mein Ohr für meine lokale Weblogic-Instanz bereitstellte. Das Löschen des lokalen Repositorys und das erneute Erstellen des Ohrs lösten das Problem für mich.

SMT_Dev
quelle