部署 Maven 项目抛出 java.util.zip.ZipException: invalid LOC header (bad signature)
Posted
技术标签:
【中文标题】部署 Maven 项目抛出 java.util.zip.ZipException: invalid LOC header (bad signature)【英文标题】：Deploying Maven project throws java.util.zip.ZipException: invalid LOC header (bad signature) 【发布时间】：2015-11-12 11:35:05 【问题描述】：运行mvn install 时出现以下异常。我什至删除了本地存储库并再次运行得到相同的异常。
[ERROR] 未能执行目标 org.apache.maven.plugins:maven-shade-plugin:2.1:shade (默认) on 项目 cores-batch：创建阴影 jar 时出错：无效的 LOC 标头 （错误签名）-> [帮助 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] 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
【问题讨论】：
针对这个问题做了一个插件-> github.com/goxr3plus/CorruptedJarsDetector @GOXR3PLUS 该仓库中没有真正的代码（自述文件中的类除外），更不用说 Maven 插件了。我认为 maven 插件实际上是最好的解决方案 - 或者只是现有插件之一的扩展，允许执行mvn dependencies validate 之类的操作......
Marco 存储库的代码是类中的代码大声笑:)
【参考方案1】：
我想练习一下。
使用您喜欢的 IDE，这里以 eclipse 为例：
-
在异常堆栈中找到合适的位置
设置条件断点
调试它
它将在异常之前打印损坏的 jar
【讨论】：
这是一个比清除整个 m2 存储库更好的解决方案，在我的情况下，它需要很长时间才能再次下载。【参考方案2】：如果您使用的是 CentOS linux 系统，Maven 本地存储库将是：
/root/.m2/repository/
您可以删除 .m2 并在开发工具中构建您的 maven 项目将解决此问题。
【讨论】：
【参考方案3】：可能与这个问题的原始原因无关，但对于那些面临 gradle 和本地模块依赖的人来说
dependencies
checkstyle project(":module")
如果模块不包含组和版本，则可能会发生此错误，因此只需在module/build.gradle 中指定
plugins
id 'java-library'
group = "com.example"
version = "master-SNAPSHOT"
【讨论】：
【参考方案4】：我在将耳朵部署到本地 weblogic 实例时遇到了这个问题。清除本地存储库并再次构建耳朵为我解决了这个问题。
【讨论】：
【参考方案5】：我们可以在 maven 中强制校验和验证，至少有两个选项：
1.将--strict-checksums 添加到我们的maven 命令中。
2.在我们的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>
更多细节在这篇文章中：https://dzone.com/articles/maven-artifact-checksums-what
【讨论】：
【参考方案6】：这是一个用Java编写的小型检测器，只需复制并运行:)
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;
输出
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)
【讨论】：
【参考方案7】：jar 文件可能已损坏。尝试删除以下文件夹的内容：
C:\Users\[username]\.m2\repository
然后右键单击您的项目，选择 Maven，更新项目，选中 Force Update of Snapshots/Releases。
【讨论】：
解决方案是修复 maven，使其至少从 repo 重新加载文件一次。查看堆栈跟踪，当时可能为时已晚，但也许 maven 在解决依赖关系时可以选择验证档案。由于这种情况经常发生 - 也许我的网络不好或其他什么，它会有所帮助。这也可以解决根本没有下载一个 jar 的情况，但是 pom 是，并且 maven 没有注意到...... 非常好.. 花了 7 个小时后，我找到了解决方案... 为你点赞...... 这可行，但删除整个 Maven 本地存储库不是最佳选择。删除相关的jar文件就行了。 不必删除所有的依赖，在顶部你可以找到哪个依赖有坏的LOC Header。 请注意：当有人在 Gradle 构建中遇到invalid LOC header 时，您只需删除 ~/.gradle/caches 文件夹 (Linux)。【参考方案8】：
此答案不适用于 DevOps/系统管理员，但适用于使用 Eclipse 等 IDE 并面临invalid LOC header (bad signature) 问题的人。
可以强制更新maven依赖，如下：
【讨论】：
【参考方案9】：除了删除 .m2/repository，从服务器中删除应用程序，运行服务器（没有应用程序），停止它并再次添加应用程序。现在它应该可以工作了。出于某种原因，仅从界面中清理服务器文件夹并没有相同的效果。
【讨论】：
【参考方案10】：您需要检查哪个 jar 出现问题。它必须被破坏。删除那个 jar 并再次运行 mvn spring-boot:run 命令。可能更多的是一个 jar 已损坏，因此每次您需要运行该命令来删除该 jar。在我的例子中，mysql、jackson、aspect jars 被 mvn spring-boot:run 命令损坏了 3 次，我发现了这一点并从 .m2 文件夹中删除了这些 jars。现在问题已经解决了。
【讨论】：
【参考方案11】：我的解决方案是运行 mvn 和 -X：
$ mvn package -X
然后向后看输出，直到看到失败，然后继续前进，直到看到 mvn 尝试处理的最后一个 jar 文件：
...
... <<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)
查看失败前的最后一个 jar 并将其从本地存储库中删除，即
$ rm -rf /Users/snowch/.m2/repository/org/eclipse/jetty/jetty-server/9.2.15.v20160210/
【讨论】：
【参考方案12】：主要问题是损坏的 jar。
要找到损坏的，您需要在 Eclipse 的断点视图中添加一个 Java 异常断点，或者您首选的 IDE，选择java.util.zip.ZipException 类，然后重新启动 Tomcat 实例。 p>
当JVM在ZipException断点处挂起时，你必须去
JarFile.getManifestFromReference() 在堆栈跟踪中，并检查属性 name 以查看文件名。
之后，您应该从文件系统中删除该文件，然后右键单击您的项目，选择 Maven，更新项目，选中强制更新快照/发布。
【讨论】：
我相信这应该是公认的答案。简单地删除数百个 jar 文件并重新下载它们并不是一个有效的解决方案。 rm -rf .m2 = 有效 那里有很棒的调试技术。使我免于浪费带宽来下载整个依赖项或工件。谢谢。 技术很棒！我找不到 JarFile 框架，但在这里发现它是 ZipFile$ZipFileInputStream.read 框架上的表达式 ZipFile.this.name。 这个损坏的 jars 的一个简单示例：***.com/a/46623719/3128926 花了 2 个小时来了解问题所在。顺便说一句，只删除相关的 jar 文件就足够了，而不是清除整个 maven 本地缓存。【参考方案13】：来自gsitgithub/find-currupt-jars.txt，以下命令列出了存储库中所有损坏的 jar 文件：
find /home/me/.m2/repository/ -name "*jar" | xargs -L 1 zip -T | grep error | grep invalid
您可以删除损坏的jar文件，然后重新编译项目。
示例输出：
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)
【讨论】：
sudo find ./repository/ -name "*jar" | sudo xargs -L 1 zip -T | grep error | grep invalid 给了我xargs: zip: No such file or directory。这是在 Windows 上的 ubuntu 上使用 bash，仅供参考
@liltitus27 这个命令行对repository下的每个jar执行zip -T（测试），然后过滤哪些jar是无效压缩文件。你有zip 命令可用吗？
似乎在 bash 中，我没有安装 zip。但是，我确实发现您发布的确切命令在 cygwin 中运行良好。而且，它还可以找到坏罐子，谢谢！
这个想法是在存储在.m2/repository 下的每个jar 上运行zip -T。在 Windows 中，您可以像我一样在 Cygwin (/cygdrive/C/Users/torno/.m2/repository) 上运行它，我认为您也可以在 Windows 10 (/mnt/c/Users/torno/.m2/repository) 上使用 Bash 运行它。我没有研究如何使用 PowerShell 编写等效脚本，我认为使用 cmd 提示符应该是不可能的。
绝对好的答案，删除 .m2 中的数千个库会损失很多。谢谢【参考方案14】：
看起来像您的 pom 文件中的 maven 编译器配置问题。 java源和目标的默认版本是1.5，即使使用JDK也有更高的版本。
要修复，添加更高java版本的maven编译器插件配置部分，例如：
<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>
有关更多信息，请查看以下链接：
maven compiler
bug report
【讨论】：
以上是关于部署 Maven 项目抛出 java.util.zip.ZipException: invalid LOC header (bad signature)的主要内容，如果未能解决你的问题，请参考以下文章