Behandlung eines ungültigen LOC-Header-Fehlers von Maven

1. Einleitung

Manchmal, wenn ein Glas in unserem lokalen Maven-Repo beschädigt ist, wird der Fehler angezeigt : Ungültiger LOC-Header .

In diesem Tutorial lernen wir, wann es passiert und wie man damit umgeht und manchmal sogar verhindert.

2. Wann tritt ein „ungültiger LOC-Header“ auf?

Maven lädt die Abhängigkeiten eines Projekts an einen bekannten Speicherort in unserem Dateisystem herunter, der als lokales Repository bezeichnet wird. Jedes Artefakt, das Maven herunterlädt, wird auch von seinen SHA1- und MD5-Prüfsummendateien begleitet:

Der Zweck dieser Prüfsummen besteht darin, die Integrität der zugehörigen Artefakte sicherzustellen. Da Netzwerke und Dateisysteme wie alles andere ausfallen können, kann es vorkommen, dass Artefakte beschädigt werden und der Inhalt des Artefakts nicht mit der Signatur übereinstimmt.

In diesen Situationen werfen Maven-Builds einen "ungültigen LOC-Header" -Fehler aus.

Die Lösung besteht darin, das beschädigte JAR aus dem Repository zu entfernen. Lassen Sie uns ein paar Möglichkeiten sehen.

3. Löschen Sie das lokale Repository

Eine schnelle Lösung für den Fehler besteht darin, das gesamte lokale Maven-Repository zu löschen und das Projekt erneut zu erstellen:

rm -rf ${LOCAL_REPOSITORY}

Dadurch wird der lokale Cache gelöscht und alle Projektabhängigkeiten erneut heruntergeladen - nicht sehr effizient.

Beachten Sie, dass sich das lokale Standard-Repository unter $ {user.home} /. M2 / repository befindet, es sei denn, wir haben es in unserem settings.xml- Tag angegeben. Wir können das lokale Repository auch über den folgenden Befehl finden: mvn help: evaluiere -Dexpression = settings.localRepository

4. Finden Sie das korrupte Glas

Eine andere Lösung besteht darin , das bestimmte beschädigte JAR zu identifizieren und aus dem lokalen Repository zu löschen .

Wenn wir den Maven Output Stack Trace-Befehl verwenden, enthält er die beschädigten JAR-Details, wenn er nicht verarbeitet werden kann.

Wir können die Protokollierung auf Debug-Ebene aktivieren, indem wir -X zum Build-Befehl hinzufügen:

mvn -X package

Die resultierende Stapelverfolgung zeigt das beschädigte Glas gegen Ende des Protokolls an. Nachdem wir das beschädigte Glas identifiziert haben, können wir es im lokalen Repository suchen und löschen. Nach dem Erstellen versucht Maven erneut, das Glas herunterzuladen.

Außerdem können wir die Integrität des Archivs mit dem Befehl zip -T testen :

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

5. Überprüfen Sie die Prüfsummen

Die beiden zuvor genannten Lösungen zwingen Maven nur, das Glas erneut herunterzuladen. Natürlich könnte das Problem bei zukünftigen Downloads erneut auftreten. Wir können dies verhindern, indem wir Maven so konfigurieren, dass die Prüfsumme beim Herunterladen des Artefakts aus einem Remote-Repository überprüft wird.

Wir können dem Maven-Befehl die Option –strict-Prüfsummen oder -C hinzufügen . Dies führt dazu, dass Maven den Build fehlschlägt, wenn die berechnete Prüfsumme nicht mit dem Wert in Prüfsummendateien übereinstimmt.

Es gibt zwei Möglichkeiten, entweder versagen die Build wenn Prüfsummen nicht übereinstimmen:

-C,--strict-checksums

oder warnen, was die Standardoption ist:

-c,--lax-checksums

Heute benötigt Maven die Signaturdateien, während Artefakte in das zentrale Repository hochgeladen werden. Es kann jedoch Artefakte im zentralen Repository geben, die nicht über die Signaturdateien verfügen , insbesondere nicht über die historischen. Aus diesem Grund ist die Standardoption warn .

Für eine dauerhaftere Lösung können wir PrüfsummePolicy in der Datei settings.xml von Maven konfigurieren . Diese Eigenschaft gibt das Verhalten an, wenn die Überprüfung einer Artefaktprüfsumme fehlschlägt. Um künftige Probleme zu vermeiden, bearbeiten wir unsere Datei settings.xml so , dass der Download fehlschlägt, wenn die Prüfsumme fehlschlägt:

    codehausSnapshots Codehaus Snapshots  false always fail     

Wir müssten dies natürlich für jedes unserer konfigurierten Repositorys tun.

6. Fazit

In dieser kurzen Beschreibung haben wir gesehen, wann ein ungültiger LOC-Headerfehler auftreten kann, und Optionen für die Behandlung.