La implementación del proyecto Maven arroja java.util.zip.ZipException: encabezado LOC no válido (firma incorrecta)

164

Recibo la siguiente excepción cuando ejecuto mi mvn install. Incluso he eliminado el repositorio local y ejecuté nuevamente obteniendo la misma excepción.

[ERROR] Error al ejecutar el objetivo org.apache.maven.plugins: maven-shade-plugin: 2.1: sombreado (predeterminado) en el lote de núcleos del proyecto: Error al crear el jar sombreado: encabezado LOC no válido (firma incorrecta) -> [Ayuda 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
fuente
1
Hizo un complemento para este problema -> github.com/goxr3plus/CorruptedJarsDetector
GOXR3PLUS
1
@ GOXR3PLUS Realmente no hay código en ese repositorio (a excepción de la clase en el archivo README), y mucho menos el de un complemento Maven. Creo que un complemento de Maven sería la mejor solución, en realidad, o simplemente una extensión de uno de los complementos existentes que permitieron hacer algo así más mvn dependencies validateo menos ...
Marco13
Marco, el código para el repositorio es el de la clase jajaja :)
GOXR3PLUS

Respuestas:

79

Debe verificar qué jar está dando problemas. Debe estar corrompido. Elimina ese jar y ejecuta el mvn spring-boot:runcomando nuevamente. Puede haber más de un jar dañado, así que cada vez que necesite ejecutar ese comando para eliminar ese jar. En mi caso, mysql, jackson, Aspect Jars se corrompió el mvn spring-boot:runcomando 3 veces y descubrí esto y eliminé los tarros de la .m2carpeta. Ahora el problema se ha resuelto.

alok
fuente
218

El archivo jar puede estar dañado. Intente eliminar el contenido de la siguiente carpeta:

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

Luego haga clic derecho en su proyecto, seleccione Maven, Actualizar proyecto, verifique Forzar actualización de instantáneas / lanzamientos.

Siva Anand
fuente
44
Esto debe ser marcado como la solución. Creo que también es la solución a varias otras preguntas relacionadas que no tienen respuestas. Gracias Siva!
Hack-R
1
muy agradable ... después de pasar 7 horas descubrí la solución ... KUDOS para ti hombre ...
Sufiyan Ansari
44
Esto funciona, pero eliminar todo el repositorio local de Maven no es la mejor opción. Simplemente elimine los archivos jar relacionados y eso es suficiente.
Levent Divilioglu
2
No tiene que eliminar todas las dependencias, en la parte superior puede encontrar qué dependencias tiene un encabezado LOC incorrecto.
umar faraz
2
Solo para notar lo obvio: cuando alguien se encuentra invalid LOC headeren la construcción de Gradle, simplemente eliminas la ~/.gradle/cachescarpeta (Linux).
Martin Vseticka
110

El problema principal son los tarros corruptos.

Para encontrar el dañado, debe agregar un punto de interrupción de excepción de Java en la vista de puntos de interrupción de Eclipse, o su IDE preferido, seleccione la java.util.zip.ZipExceptionclase y reinicie la instancia de Tomcat.

Cuando la JVM se suspende en el ZipExceptionpunto de interrupción, debe ir al JarFile.getManifestFromReference()seguimiento de la pila y verificar el atributo namepara ver el nombre del archivo.

Después de eso, debe eliminar el archivo del sistema de archivos y luego hacer clic con el botón derecho en su proyecto, seleccionar Maven, Actualizar proyecto, verificar Forzar actualización de instantáneas / lanzamientos.

Matias Sebastiao
fuente
11
Creo que esta debería ser la respuesta aceptada. Simplemente eliminar cientos de archivos jar y volver a descargarlos no es una solución eficiente.
Mohsen
11
rm -rf .m2 = efectivo
Jeryl Cook
2
Impresionante técnica de depuración allí. Me salvó de malgastar el ancho de banda para descargar todas las dependencias o artefactos. Gracias.
Thariq Nugrohotomo
3
¡Gran técnica! No pude encontrar el marco JarFile, pero aquí lo encontré como la expresión ZipFile.this.name en el marco ZipFile $ ZipFileInputStream.read.
rlpatrao
2
Un ejemplo simple de estos frascos corruptos: stackoverflow.com/a/46623719/3128926 Tardó 2 horas para comprender cuál es el problema. Por cierto, eliminar solo archivos jar relacionados es suficiente en lugar de borrar todo el caché local maven.
Levent Divilioglu
41

Desde gsitgithub / find-currupt-jars.txt , el siguiente comando enumera todos los archivos jar corruptos en el repositorio:

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

Puede eliminar los archivos jar dañados y volver a compilar el proyecto.

Salida de ejemplo:

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
fuente
1
sudo find ./repository/ -name "*jar" | sudo xargs -L 1 zip -T | grep error | grep invalid me da xargs: zip: No such file or directory. esto es usando bash en ubuntu en las ventanas, FYI
liltitus27
1
@ liltitus27 Esta línea de comando se ejecuta zip -T(prueba) en cada jarra debajo repositoryy luego filtra qué jarras son archivos comprimidos no válidos. ¿Tienes zipcomando disponible?
Javier
parece que en bash, no tengo zip instalado. Sin embargo, encontré que el comando exacto que publicaste funciona maravillosamente en cygwin. y también funcionó para encontrar frascos malos, ¡gracias!
liltitus27
2
¡Eres el mejor hombre!
Igor Masternoy
La idea es ejecutar zip -Ten cada jarra almacenada en .m2/repository. En Windows, puede ejecutarlo en Cygwin ( /cygdrive/C/Users/torno/.m2/repository) como lo hice yo, y creo que también puede ejecutarlo con Bash en Windows 10 ( /mnt/c/Users/torno/.m2/repository). No investigué cómo escribir un script equivalente con PowerShell, y creo que no debería ser posible con un indicador de cmd.
Javier
11

Me gustaría dar mi dar mi práctica.

Use su IDE preferido, tome eclipse por ejemplo aquí:

  1. Encuentre una ubicación adecuada dentro de la pila de excepciones
  2. Establecer punto de interrupción condicional
  3. Depurarlo
  4. Imprimirá el jar dañado antes de la excepción

ingrese la descripción de la imagen aquí

samm
fuente
1
Esta es una solución mucho mejor que borrar todo el repositorio m2, que en mi caso llevaría años volver a descargar.
Martin Cassidy
5

La solución para mí fue correr mvncon -X:

$ mvn package -X

Luego mire hacia atrás a través de la salida hasta que vea la falla y luego continúe hasta que vea el último archivo jar que mvn intentó procesar:

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

Mire el último frasco antes de que falle y elimínelo del repositorio local, es decir

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

Parece un problema de configuración para el compilador maven en su archivo pom. La versión predeterminada de origen y destino de Java es 1.5, incluso el JDK utilizado tiene una versión más alta.

Para solucionarlo, agregue la sección de configuración del complemento del compilador maven con una versión superior de Java, por ejemplo:

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

Para obtener más información, consulte estos enlaces:

compilador maven

informe de error

harvyS
fuente
1

Esta respuesta no es para DevOps / administradores de sistemas, sino para aquellos que usan IDE como eclipse y enfrentan invalid LOC header (bad signature)problemas.

Puede forzar la actualización de las dependencias de Maven de la siguiente manera:

ingrese la descripción de la imagen aquí

ingrese la descripción de la imagen aquí

Vishrant
fuente
1

Aquí hay un pequeño detector escrito en Java, solo copie y ejecute :) 

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

}

Salida

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

Podemos forzar la validación de suma de comprobación en maven con al menos dos opciones:

1.Agregando el --strict-checksumscomando a nuestro experto.

2.Agregando la siguiente configuración a nuestro archivo de configuración de 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>

Más detalles en esta publicación: https://dzone.com/articles/maven-artifact-checksums-what

SHoko
fuente
0

Más allá de eliminar .m2 / repositorio, elimine la aplicación del servidor, ejecute el servidor (sin aplicaciones), deténgala y agregue la aplicación nuevamente. Ahora se supone que funciona. Por alguna razón, simplemente limpiar las carpetas del servidor desde la interfaz no tiene el mismo efecto.

Alex
fuente
0

Estaba enfrentando este problema mientras desplegaba mi oído en mi instancia local de weblogic. Borrar el repositorio local y construir el oído nuevamente resolvió el problema por mí.

SMT_Dev
fuente