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 <localRepository> . Мы также можем найти локальный репозиторий с помощью команды: mvn help:evaluate -Dexpression=settings.localRepository
4. Найдите поврежденную банку
Другое решение состоит в том, чтобы идентифицировать конкретную поврежденную банку и удалить ее из локального репозитория .
Когда мы используем команду трассировки выходного стека 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 требует файлы подписи при загрузке артефактов в центральный репозиторий. Но в центральном репозитории могут быть артефакты, не содержащие файлы сигнатур , особенно исторические. Вот почему опция по умолчанию — warn .
Для более постоянного решения мы можем настроить 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, и варианты того, как с ней справиться.