«1. Введение
Иногда, когда jar в нашем локальном репозитории Maven поврежден, мы видим ошибку: Invalid LOC Header.
В этом уроке мы узнаем, когда это происходит, и как с этим бороться, а иногда и предотвращать.
2. Когда возникает «Недопустимый заголовок LOC»?
Maven загружает зависимости проекта в известное место в нашей файловой системе, называемое локальным репозиторием. Каждый артефакт, загружаемый Maven, также сопровождается файлами контрольных сумм SHA1 и MD5:
Целью этих контрольных сумм является обеспечение целостности связанных артефактов. Поскольку сети и файловые системы могут выходить из строя, как и все остальное, иногда артефакты повреждаются, в результате чего содержимое артефакта не соответствует сигнатуре.
В таких ситуациях сборки Maven выдают ошибку «недопустимый заголовок LOC».
Решение состоит в том, чтобы удалить поврежденную банку из репозитория. Давайте посмотрим пару способов.
3. Удалите локальный репозиторий
Быстрое исправление ошибки заключается в удалении всего локального репозитория Maven и повторной сборке проекта:
rm -rf ${LOCAL_REPOSITORY}
Это удалит локальный кеш и повторно загрузит все зависимости проекта – не очень эффективны.
Обратите внимание, что локальный репозиторий по умолчанию находится в ${user.home}/.m2/repository, если только мы не указали его в нашем теге settings.xml \u003clocalRepository\u003e. Мы также можем найти локальный репозиторий с помощью команды: mvn help:evaluate -Dexpression=settings.localRepository
4. Найти поврежденный JAR
Другое решение — определить конкретный поврежденный JAR и удалить его из локального репозитория.
Когда мы используем команду трассировки выходного стека Maven, она будет содержать поврежденные детали jar, если не сможет ее обработать.
Мы можем включить ведение журнала уровня отладки, добавив -X в команду сборки:
mvn -X package
Полученная трассировка стека укажет на поврежденный jar ближе к концу журнала. Обнаружив поврежденную банку, мы можем найти ее в локальном репозитории и удалить. Теперь после сборки Maven повторит попытку загрузки jar.
Кроме того, мы можем проверить целостность архива с помощью команды zip -T:
find ${LOCAL_REPOSITORY} -name "*.jar" | xargs -L 1 zip -T | grep error
5. Подтвердить контрольные суммы
Два решения, упомянутые ранее, только заставят Maven повторно загрузить банку. Конечно, проблема может возникнуть снова при будущих загрузках. Мы можем предотвратить это, настроив Maven для проверки контрольной суммы при загрузке артефакта из удаленного репозитория.
Мы можем добавить параметр —strict-checksums или -C в команду Maven. Это приведет к сбою сборки Maven, если вычисленная контрольная сумма не соответствует значению в файлах контрольной суммы.
Есть два варианта: либо завершить сборку, если контрольные суммы не совпадают:
-C,--strict-checksums
, либо предупредить, что является вариантом по умолчанию:
-c,--lax-checksums
Сегодня Maven требует файлы подписи при загрузке артефактов в центральный репозиторий. Но в центральном репозитории могут быть артефакты, в которых нет файлов сигнатур, особенно исторических. Вот почему опция по умолчанию — предупреждение.
Для более постоянного решения мы можем настроить checksumPolicy в файле Maven settings.xml. Это свойство определяет поведение при сбое проверки контрольной суммы артефакта. Чтобы избежать проблем в будущем, давайте отредактируем наш файл 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>
Нам, конечно, нужно сделать это для каждого из настроенных репозиториев.
6. Заключение
В этом кратком обзоре мы рассмотрели, когда может возникнуть ошибка недопустимого заголовка LOC, и способы ее обработки.