Implementatie van Maven-project genereert java.util.zip.ZipException: ongeldige LOC-header (slechte handtekening)

Ik krijg de onderstaande uitzondering wanneer ik mijn mvn installuitvoer. Ik heb zelfs de lokale repository verwijderd en opnieuw uitgevoerd om dezelfde uitzondering te krijgen.

[ERROR] Doel niet uitvoeren
org.apache.maven.plugins:maven-shade-plugin:2.1:shade (standaard) aan
project cores-batch: fout bij het maken van een gearceerde pot: ongeldige LOC-header
(slechte handtekening) -> [Help 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>

FOUT:

[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

Antwoord 1, autoriteit 100%

Je moet controleren welke pot een probleem geeft. Het moet beschadigd zijn. Verwijder die jar en voer de opdracht mvn spring-boot:runopnieuw uit. Het kan zijn dat er meer dan één pot is beschadigd, dus elke keer dat u die opdracht moet uitvoeren om die pot te verwijderen. In mijn geval was mysql, jackson, aspect jars 3 keer beschadigd mvn spring-boot:runcommando en ik kwam hier achter en verwijderde de jars uit de map .m2. Nu is het probleem opgelost.

Antwoord 2, autoriteit 93%

Het jar-bestand is mogelijk beschadigd. Probeer de inhoud van de volgende map te verwijderen:

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

Klik vervolgens met de rechtermuisknop op uw project, selecteer Maven, Project bijwerken en vink Forceer update van snapshots/releases aan.

Antwoord 3, autoriteit 91%

Het grootste probleem zijn beschadigde potten.

Om de beschadigde te vinden, moet u een Java Exception Breakpointtoevoegen in de Breakpoints View van Eclipse, of uw favoriete IDE, selecteer de java.util.zip.ZipExceptionclass en start Tomcat-instantie opnieuw.

Als de JVM stopt bij ZipExceptionbreekpunt, moet je naar
JarFile.getManifestFromReference()in de stacktracering en vink attribuut nameaan om de bestandsnaam te zien.

Daarna moet u het bestand uit het bestandssysteem verwijderen en vervolgens met de rechtermuisknop op uw project klikken, Maven, Project bijwerken selecteren, aanvinken Force Update of Snapshots/Releases.

Antwoord 4, autoriteit 48%

Van gsitgithub/find-currupt-jars.txt, geeft het volgende commando alle beschadigde jar-bestanden in de repository:

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

U kunt de beschadigde jar-bestanden verwijderen en het project opnieuw compileren.

Voorbeelduitvoer:

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)

Antwoord 5, autoriteit 13%

Ik wil graag mijn praktijk geven.

Gebruik uw favoriete IDE, neem bijvoorbeeld eclipse hier:

1. Zoek een geschikte locatie binnen de uitzonderingsstapel
2. Voorwaardelijk breekpunt instellen
3. Debug het
4. Het zal de beschadigde pot vóór de uitzondering afdrukken

Antwoord 6, autoriteit 7%

De oplossing voor mij was om mvnuit te voeren met -X:

$ mvn package -X

Kijk dan achteruit door de uitvoer totdat je de fout ziet en ga dan door totdat je het laatste jar-bestand ziet dat mvn probeerde te verwerken:

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

Kijk naar de laatste pot voordat deze mislukte en verwijder die uit de lokale repository, d.w.z.

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

Antwoord 7, autoriteit 2%

Het lijkt op een configuratieprobleem voor de maven-compiler in je pom-bestand. Standaard versie java bron en doel is 1.5, zelfs gebruikte JDK heeft een hogere versie.

Om dit op te lossen, voegt u de configuratiesectie van de maven compiler-plug-in toe met een hogere Java-versie, bijvoorbeeld:

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

Bekijk deze links voor meer informatie:

maven-compiler

bugrapport

Antwoord 8

Dit antwoord is niet voor DevOps/systeembeheerders, maar voor hen die IDE gebruiken zoals eclipse en geconfronteerd worden met een invalid LOC header (bad signature)-probleem.

U kunt de maven-afhankelijkheden als volgt forceren:

Antwoord 9

Hier is een kleine detector geschreven in Java, gewoon kopiëren en uitvoeren 🙂

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

Uitvoer

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)

Antwoord 10

We kunnen de checksum-validatie in maven forceren met ten minste twee opties:

1.De --strict-checksumstoevoegen aan ons maven-commando.

2.De volgende configuratie toevoegen aan ons maven-instellingenbestand:

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

Meer details in dit bericht: https://dzone.com/articles/maven -artefact-checksums-wat

Antwoord 11

Naast het verwijderen van .m2/repository, verwijder de applicatie van de server, voer de server uit (zonder applicaties), stop deze en voeg de applicatie opnieuw toe. Nu zou het moeten werken. Om de een of andere reden heeft het opschonen van servermappen vanuit de interface niet hetzelfde effect.

Antwoord 12

Ik werd met dit probleem geconfronteerd toen ik mijn oor op mijn lokale weblogic-instantie implementeerde. Het wissen van de lokale repository en het opnieuw bouwen van het oor loste het probleem voor mij op.

Antwoord 13

Misschien niet gerelateerd aan de oorspronkelijke reden in deze vraag, maar voor degenen die hetzelfde zouden tegenkomen met gradle en lokale module-afhankelijkheid

dependencies {
    checkstyle project(":module")
}

deze fout kan optreden als de module geen groep en versie bevat, dus in de module/build.gradlehoeft u alleen maar te specificeren

plugins {
    id 'java-library'
}
group = "com.example"
version = "master-SNAPSHOT"

Antwoord 14

Als je het CentOS Linux-systeem gebruikt, is de lokale Maven-repositary:

/root/.m2/repository/

U kunt .m2 verwijderen en uw maven-project bouwen in de dev-tool om het probleem op te lossen.