1. Въведение
Понякога, когато буркан в нашия локален репозитор на Maven е повреден, ще видим грешката: Невалиден заглавие на LOC .
В този урок ще научим кога се случва и как да се справим и дори понякога да го предотвратим.
2. Кога се появява „Невалидна заглавка на LOC“?
Maven изтегля зависимостите на проекта на известно място в нашата файлова система, наречено локално хранилище. Всеки артефакт, който Maven изтегля, също е придружен от своите SHA1 и MD5 файлове с контролна сума:
Целта на тези контролни суми е да осигурят целостта на свързаните артефакти. Тъй като мрежите и файловите системи могат да се провалят, както и всичко друго, има моменти, когато артефактите се повреждат, което прави съдържанието на артефакта да не съвпада с подписа.
В тези ситуации Maven компилации изхвърля грешка „невалиден LOC заглавие“.
Решението е да се премахне повреденият буркан от хранилището. Нека да видим няколко начина.
3. Изтрийте локалното хранилище
Бърза корекция на грешката е да изтриете цялото локално хранилище на Maven и да изградите проекта отново:
rm -rf ${LOCAL_REPOSITORY}Това ще изтрие локалния кеш и ще изтегли отново всички зависимости на проекта - не е много ефективно.
Обърнете внимание, че локалното хранилище по подразбиране е $ {user.home} /. M2 / хранилище, освен ако не сме го посочили в нашия етикет settings.xml . Също така можем да намерим локалното хранилище чрез командата: mvn help: evalua -Dexpression = settings.localRepository
4. Намерете корумпирания буркан
Друго решение е да се идентифицира конкретният корумпиран буркан и да се изтрие от локалното хранилище .
Когато използваме командата за проследяване на изходен стек на Maven, тя ще съдържа подробности за повредените буркани, когато не успее да я обработи.
Можем да активираме регистриране на ниво на отстраняване на грешки, като добавим -X към командата за изграждане:
mvn -X packageПолучената проследяване на стека ще показва повредения буркан към края на дневника. След като идентифицираме повредения буркан, можем да го намерим в локалното хранилище и да го изтрием. Сега при изграждането, Maven ще опита отново да изтегли буркана.
Също така можем да тестваме целостта на архива с командата zip -T :
find ${LOCAL_REPOSITORY} -name "*.jar" | xargs -L 1 zip -T | grep error5. Проверка на контролни суми
Двете решения, споменати по-рано, само ще принудят Maven да изтегли отново буркана. Разбира се, проблемът може да възникне отново при бъдещи изтегляния. Можем да предотвратим това, като конфигурираме Maven да проверява контролната сума, докато изтегля артефакта от отдалечено хранилище.
Можем да добавим опцията –strict-checksums или -C към командата Maven. Това ще доведе до неуспешно компилиране на Maven, ако изчислената контролна сума не съвпада със стойността във файловете с контролна сума.
Има две опции, или да се провали компилацията, ако контролните суми не съвпадат:
-C,--strict-checksumsили предупреждавайте коя е опцията по подразбиране:
-c,--lax-checksumsДнес Maven изисква файловете с подписи, докато качва артефакти в централното хранилище. Но може да има артефакти в централното хранилище, които нямат файловете с подписи , особено историческите. Ето защо опцията по подразбиране се предупреждава .
За по-постоянно решение можем да конфигурираме checkumPolicy във файла settings.xml на Maven . Това свойство определя поведението, когато проверката на артефактната контролна сума е неуспешна. За да избегнем проблеми в бъдеще, нека редактираме нашия файл settings.xml, за да не успеем при изтеглянето, когато контролната сума не успее:
codehausSnapshots Codehaus Snapshots false always fail Разбира се, ще трябва да направим това за всяко от нашите конфигурирани хранилища.
6. Заключение
В това бързо писане видяхме кога може да възникне невалидна грешка в заглавката на LOC и опции за това как да се справим.