La distribuzione del progetto Maven genera java.util.zip.ZipException: intestazione LOC non valida (firma non valida)


164

Ricevo l'eccezione di seguito quando eseguo il mio mvn install. Ho persino cancellato il repository locale e ho eseguito nuovamente ottenendo la stessa eccezione.

[ERRORE] Impossibile eseguire l'obiettivo org.apache.maven.plugins: maven-shade-plugin: 2.1: shade (impostazione predefinita) sul core del progetto: errore durante la creazione del jar ombreggiato: intestazione LOC non valida (firma non valida) -> [Guida 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>

Errore:

[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

1
Creato un plug-in per questo problema -> github.com/goxr3plus/CorruptedJarsDetector
GOXR3PLUS

1
@ GOXR3PLUS Non c'è davvero codice in quel repository (ad eccezione della classe nel README), tanto meno quello di un plugin Maven. Penso che un plugin maven sarebbe la soluzione migliore, in realtà - o solo un'estensione di uno dei plugin esistenti che ha permesso di fare qualcosa del genere mvn dependencies validate...
Marco13

Marco il codice per il repository è quello in classe lol :)
GOXR3PLUS

Risposte:


79

Devi controllare quale vaso sta dando problemi. Deve essere corrotto. Elimina quel vaso ed esegui di mvn spring-boot:runnuovo il comando. Può trattarsi di più di un vaso danneggiato, quindi ogni volta che è necessario eseguire quel comando per eliminare quel vaso. Nel mio caso mysql, jackson, jars aspetto è stato danneggiato il mvn spring-boot:runcomando 3 volte e ho capito questo e cancellato i barattoli dalla .m2cartella. Ora il problema è stato risolto.


218

Il file jar potrebbe essere danneggiato. Prova a rimuovere il contenuto della seguente cartella:

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

Quindi fai clic con il pulsante destro del mouse sul progetto, seleziona Maven, Aggiorna progetto, controlla Forza aggiornamento di istantanee / rilasci.


4
Questo dovrebbe essere contrassegnato come soluzione. Credo che sia anche la soluzione a molte altre domande correlate che non hanno risposte. Grazie Siva!
Hack-R,

1
molto bello .. dopo aver trascorso 7 ore ho scoperto la soluzione ... KUDOS per te amico ....
Sufiyan Ansari

4
Funziona ma eliminare l'intero repository locale maven non è l'opzione migliore. Basta eliminare i file jar correlati e basta.
Levent Divilioglu,

2
Non è necessario eliminare tutte le dipendenze, in alto è possibile trovare quali dipendenze ha un'intestazione LOC errata.
Umar Faraz,

2
Solo per notare l'ovvio: quando qualcuno si imbatte invalid LOC headerin Gradle build, è sufficiente eliminare la ~/.gradle/cachescartella (Linux).
Martin Vseticka,

110

Il problema principale sono i vasetti corrotti.

Per trovare quello danneggiato, è necessario aggiungere un Breakpoint di eccezione Java nella vista Breakpoint di Eclipse o l'IDE preferito, selezionare la java.util.zip.ZipExceptionclasse e riavviare l'istanza Tomcat.

Quando la JVM si interrompe al ZipExceptionpunto di interruzione, è necessario andare JarFile.getManifestFromReference()nella traccia dello stack e controllare l'attributo nameper vedere il nome del file.

Successivamente, è necessario eliminare il file dal file system e quindi fare clic con il pulsante destro del mouse sul progetto, selezionare Maven, Aggiorna progetto, controllare Forza aggiornamento di istantanee / rilasci.


11
Credo che questa dovrebbe essere la risposta accettata. Rimuovere semplicemente centinaia di file jar e scaricarli nuovamente non è una soluzione efficiente.
Mohsen,

11
rm -rf .m2 = efficace
Jeryl Cook

2
Impressionante tecnica di debug lì. Mi ha salvato dallo spreco di larghezza di banda per scaricare tutte le dipendenze o gli artefatti. Grazie.
Thariq Nugrohotomo

3
Grande tecnica! Non ho trovato il frame JarFile, ma qui l'ho trovato come espressione ZipFile.this.name sul frame ZipFile $ ZipFileInputStream.read.
rlpatrao,

2
Un semplice esempio di questo vasetti corrotti: stackoverflow.com/a/46623719/3128926 Ci sono voluti 2 ore per capire qual è il problema. A proposito, è sufficiente rimuovere solo i file jar correlati invece di svuotare l'intera cache locale di Maven.
Levent Divilioglu,

41

Da gsitgithub / find-currupt-jars.txt , il seguente comando elenca tutti i file jar danneggiati nel repository:

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

È possibile eliminare i file jar danneggiati e ricompilare il progetto.

Esempio di output:

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)

1
sudo find ./repository/ -name "*jar" | sudo xargs -L 1 zip -T | grep error | grep invalid mi dà xargs: zip: No such file or directory. questo sta usando bash su ubuntu su windows, fyi
liltitus27

1
@ liltitus27 Questa riga di comando esegue zip -T(test) su ogni vaso sotto repository, quindi filtra quali barattoli sono file compressi non validi. Hai un zipcomando disponibile?
Javier,

sembra che in bash non ho installato zip. ho scoperto che l'esatto comando che hai pubblicato funziona magnificamente in Cygwin, tuttavia. e anche, ha funzionato nel trovare barattoli cattivi, grazie!
liltitus27,

2
Sei il migliore, UOMO!
Igor Masternoy,

L'idea è quella di funzionare zip -Tsu ogni vaso sotto .m2/repository. In Windows, puoi eseguirlo su Cygwin ( /cygdrive/C/Users/torno/.m2/repository) come ho fatto io, e penso che puoi anche eseguirlo con Bash su Windows 10 ( /mnt/c/Users/torno/.m2/repository). Non ho studiato come scrivere uno script equivalente con PowerShell e penso che non dovrebbe essere possibile con un prompt cmd.
Javier,

11

Vorrei dare la mia pratica.

Usa il tuo IDE preferito, prendi eclissi per esempio qui:

  1. Trova una posizione appropriata nello stack delle eccezioni
  2. Imposta breakpoint condizionale
  3. Esegui il debug
  4. Stamperà il vaso danneggiato prima dell'eccezione

inserisci qui la descrizione dell'immagine


1
Questa è una soluzione di gran lunga migliore della cancellazione dell'intero repository m2, che nel mio caso richiederebbe di nuovo il download.
Martin Cassidy,

5

La soluzione per me era correre mvncon -X:

$ mvn package -X

Quindi guarda indietro attraverso l'output fino a quando non vedi l'errore e poi continua fino a quando non vedi l'ultimo file jar che mvn ha tentato di elaborare:

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

Guarda l'ultimo barattolo prima che fallisca e rimuovilo dal repository locale, ad es

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

2

Sembra un problema di configurazione per il compilatore Maven nel tuo file pom. La versione predefinita di java source e target è 1.5, anche se JDK ha una versione successiva.

Per risolvere, aggiungi la sezione di configurazione del plugin del compilatore maven con una versione java superiore, ad esempio:

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

Per maggiori informazioni controlla questi link:

compilatore Maven

riportare un errore


1

Questa risposta non è per i ragazzi di DevOps / amministratore di sistema, ma per quelli che usano IDE come eclissi e devono affrontare invalid LOC header (bad signature)problemi.

È possibile forzare l'aggiornamento delle dipendenze di Maven, come indicato di seguito:

inserisci qui la descrizione dell'immagine

inserisci qui la descrizione dell'immagine


1

Ecco un piccolo rilevatore scritto in Java, basta copiare ed eseguire :)

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

}

Produzione

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)

1

Possiamo forzare la convalida del checksum in Maven con almeno due opzioni:

1.Aggiunta --strict-checksumsal nostro comando maven .

2.Aggiunta della seguente configurazione al nostro file delle impostazioni di 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>

Maggiori dettagli in questo post: https://dzone.com/articles/maven-artifact-checksums-what


0

Oltre a rimuovere .m2 / repository, rimuovere l'applicazione dal server, eseguire il server (senza applicazioni), arrestarlo e aggiungere nuovamente l'applicazione. Ora dovrebbe funzionare. Per qualche motivo, semplicemente ripulire le cartelle del server dall'interfaccia non ha lo stesso effetto.


0

Stavo affrontando questo problema durante la distribuzione dell'orecchio alla mia istanza weblogic locale. Cancellare l'archivio locale e costruire di nuovo l'orecchio ha risolto il problema per me.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.