1. Introduction

1.绪论

Sometimes when a jar in our local Maven repo is corrupt, we’ll see the error: Invalid LOC Header.

有时，当我们本地Maven repo中的jar损坏时，我们会看到这样的错误。无效的LOC头。

In this tutorial, we’re going to learn when it happens and how to handle and even at times prevent it.

在本教程中，我们将学习何时发生这种情况，以及如何处理和甚至有时防止它。

2. When Does “Invalid LOC Header” Occur?

2.什么时候会出现 “无效的LOC头”？

Maven downloads a project’s dependencies into a known location on our filesystem called a local repository. Every artifact that Maven downloads is also accompanied by its SHA1 and MD5 checksum files:

Maven将项目的依赖项下载到我们文件系统中的一个已知位置，称为local repository。Maven下载的每个工件都有其SHA1和MD5校验文件。

The purpose of these checksums is to ensure the integrity of the associated artifacts. Since networks and file systems can fail, just like anything else, there are times when artifacts get corrupted, making the artifact contents not match the signature.

这些校验和的目的是为了确保相关工件的完整性。由于网络和文件系统可能会失败，就像其他东西一样，有时工件会被损坏，使工件内容与签名不一致。

In these situations, Maven builds throw an “invalid LOC header” error.

在这种情况下，Maven构建时会出现 “无效的LOC头 “错误。

The solution is to remove the corrupt jar from the repository. Let’s see a couple of ways.

解决方案是将损坏的jar从版本库中删除。让我们看看几个方法。

3. Delete the Local Repository

3.删除本地存储库

A quick-fix for the error is to delete the whole Maven local repository and build the project again:

快速解决该错误的方法是删除整个Maven本地仓库并重新构建项目：。

rm -rf ${LOCAL_REPOSITORY}

This will erase the local cache and re-download all the project dependencies – not very efficient.

这将清除本地缓存并重新下载所有的项目依赖 – 效率不高。。

Note that the default local repository is at ${user.home}/.m2/repository unless we specified it in our settings.xml <localRepository> tag. We can also find the local repository by the command: mvn help:evaluate -Dexpression=settings.localRepository

注意，默认的本地仓库在${user.home}/.m2/repository，除非我们在settings.xml<localRepository>标签中指定。我们也可以通过以下命令找到本地仓库。mvn help:evaluation -Dexpression=settings.localRepository。

4. Find the Corrupt Jar

4.找到腐败的罐子

Another solution is to identify the specific corrupt jar and delete it from the local repository.

另一个解决方案是识别特定的损坏的jar并从本地存储库中删除它。

When we use the Maven output stack trace command, it’ll contain the corrupt jar details when it fails to process it.

当我们使用Maven的输出堆栈跟踪命令时，它将包含处理失败的jar的细节。

We can enable debug level logging by adding -X to the build command:

我们可以通过在构建命令中添加-X来启用调试级别的日志。

mvn -X package

The resulting stack trace will indicate the corrupted jar towards the end of the log. After identifying the corrupted jar, we can locate it in the local repository and delete it. Now upon build, Maven will retry downloading the jar.

由此产生的堆栈跟踪将在日志的最后部分指出损坏的jar。确定损坏的jar后，我们可以在本地仓库中找到它并删除。现在在构建时，Maven会重新尝试下载该jar。

Also, we can test the integrity of the archive with the zip -T command:

另外，我们可以用zip -T命令测试存档的完整性。

find ${LOCAL_REPOSITORY} -name "*.jar" | xargs -L 1 zip -T | grep error

5. Validate Checksums

5.验证校验和

The two solutions mentioned earlier will only force Maven to re-download the jar. Of course, the issue could occur again in future downloads. We can prevent that by configuring Maven to validate the checksum while downloading the artifact from a remote repository.

前面提到的两种解决方案只会迫使Maven重新下载jar。当然，这个问题可能在以后的下载中再次出现。我们可以通过配置Maven，使其在从远程仓库下载工件时验证校验和，来防止这种情况。

We can add the –strict-checksums or -C option to the Maven command. This will cause Maven to fail the build if the computed checksum doesn’t match the value in checksum files.

我们可以在Maven命令中添加-strict-checksums或-C选项。如果计算的校验和与校验文件中的值不一致，这将导致Maven构建失败。

There are two options, either to fail the build if checksums don’t match:

有两个选项，如果校验和不匹配，可以选择fail build。

-C,--strict-checksums

or warn which is the default option:

或warn，这是默认选项。

-c,--lax-checksums

Today Maven requires the signature files while uploading artifacts to the central repository. But there might be artifacts in the central repository that don’t have the signature files, particularly the historic ones. That is why the default option is warn.

今天，Maven在将工件上传到中央仓库时需要签名文件。但中央仓库中可能有一些工件没有签名文件，特别是历史性的工件。这就是为什么默认选项是warn。

For a more permanent solution, we can configure checksumPolicy in Maven’s settings.xml file. This property specifies the behavior when verification of an artifact checksum fails. To avoid problems in the future, let’s edit our settings.xml file to fail the download when the checksum fails:

为了获得更持久的解决方案，我们可以在Maven的settings.xml文件中配置checksumPolicy。该属性指定了工件校验失败时的行为。为了避免将来出现问题，让我们编辑settings.xml文件，以便在校验失败时不能进行下载。

<profiles>
    <profile>
        <repositories>
            <repository>
                <id>codehausSnapshots</id>
                <name>Codehaus Snapshots</name>
                <releases>
                    <enabled>false</enabled>
                    <updatePolicy>always</updatePolicy>
                    <checksumPolicy>fail</checksumPolicy>
                </releases>
            </repository>
        </repository>
    </profile>
</profiles>

We’d, of course, need to do this for each of our configured repositories.

当然，我们需要为我们配置的每一个存储库做这件事。

6. Conclusion

6.结语

In this quick write-up, we’ve seen when an invalid LOC header error can occur and options for how to handle it.

在这篇快速的文章中，我们看到了什么时候会发生无效的LOC头错误以及如何处理它的选项。