streamalism.org

1. Introduktion

Nogle gange når en krukke i vores lokale Maven repo er korrupt, ser vi fejlen: Ugyldig LOC-overskrift.

I denne vejledning lærer vi, hvornår det sker, og hvordan man håndterer og selv til tider forhindre det.

2. Hvornår forekommer "Ugyldig LOC-header"?

Maven downloader et projekts afhængighed til et kendt sted på vores filsystem kaldet et lokalt lager. Hver artefakt, som Maven downloader, ledsages også af dens SHA1- og MD5-kontrolsumfiler:

Formålet med disse kontrolsummer er at sikre integriteten af ​​de tilknyttede artefakter. Siden netværk og filsystemer kan mislykkes, ligesom alt andet er der tidspunkter, hvor artefakter bliver ødelagt, hvilket gør, at artefaktindholdet ikke svarer til signaturen.

I disse situationer bygger Maven en "ugyldig LOC-header" -fejl.

Løsningen er at fjerne den korrupte krukke fra lageret. Lad os se et par måder.

3. Slet det lokale lager

En hurtig løsning til fejlen er at slet hele Maven lokale arkiv og opbyg projektet igen:

rm -rf $ {LOCAL_REPOSITORY}

Dette sletter den lokale cache og downloader alle projektafhængigheder igen - ikke særlig effektiv.

Bemærk, at standard lokalt lager er på $ {user.home} /. m2 / lager medmindre vi specificerede det i vores settings.xml tag. Vi kan også finde det lokale lager ved kommandoen: mvn hjælp: evaluere -Dexpression = settings.localRepository

4. Find den korrupte krukke

En anden løsning er at identificer den specifikke korrupte jar og slet den fra det lokale lager.

Når vi bruger sporingskommandoen Maven output stack, indeholder den de korrupte jar-detaljer, når den ikke behandler den.

Vi kan aktivere fejlfindingslogning ved at tilføje -X til build-kommandoen:

mvn -X pakke

Den resulterende staksporing vil indikere den beskadigede krukke mod slutningen af ​​loggen. Efter at have identificeret den beskadigede krukke, kan vi finde den i det lokale lager og slette den. Nu efter opførelsen prøver Maven igen at downloade krukken.

Vi kan også teste arkivets integritet med lynlås -T kommando:

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

5. Valider kontrolsummer

De to tidligere nævnte løsninger vil kun tvinge Maven til at downloade krukken igen. Naturligvis kan problemet opstå igen i fremtidige downloads. Vi kan forhindre det ved at konfigurere Maven til at validere kontrolsummen, mens vi downloader artefakten fra et eksternt lager.

Vi kan tilføje –Streng-kontrolsummer eller -C indstilling til Maven-kommandoen. Dette får Maven til at mislykkes med build, hvis den beregnede kontrolsum ikke matcher værdien i kontrolsumfiler.

Der er to muligheder, enten til svigte build hvis kontrolsummer ikke stemmer overens:

-C, - strenge kontrolsummer

eller advare som er standardindstillingen:

-c, - slap kontrolsummer

I dag kræver Maven signaturfiler, mens de uploader artefakter til det centrale lager. Men der kan være artefakter i det centrale lager, der ikke har signaturfilerne, især de historiske. Derfor er standardindstillingen advare.

For en mere permanent løsning kan vi konfigurere kontrolsumPolitik i Maven's settings.xml fil. Denne egenskab specificerer adfærd, når verifikation af en artefaktkontrolsum mislykkes. Lad os redigere vores for at undgå problemer i fremtiden settings.xml fil til ikke at downloade, når kontrolsummen mislykkes:

    codehausSnapshots Codehaus Snapshots falske mislykkes altid 

Vi skal selvfølgelig gøre dette for hver af vores konfigurerede arkiver.

6. Konklusion

I denne hurtige opskrivning har vi set, hvornår en ugyldig LOC-headerfejl kan opstå, og muligheder for, hvordan den skal håndteres.