streamalism.org

1. Introduksjon

Noen ganger når en krukke i vår lokale Maven repo er korrupt, ser vi feilen: Ugyldig LOC-topptekst.

I denne opplæringen skal vi lære når det skjer og hvordan vi skal håndtere og selv til tider forhindre det.

2. Når forekommer “Ugyldig LOC-overskrift”?

Maven laster ned avhengighetene til et prosjekt til et kjent sted i filsystemet vårt som kalles et lokalt arkiv. Hver gjenstand som Maven laster ned, blir også ledsaget av SHA1- og MD5-kontrollsumfiler:

Formålet med disse kontrollsummene er å sikre integriteten til de tilknyttede gjenstandene. Siden nettverk og filsystemer kan mislykkes, akkurat som noe annet, er det tider når gjenstander blir ødelagt, slik at gjenstandsinnholdet ikke samsvarer med signaturen.

I disse situasjonene bygger Maven en "ugyldig LOC-header" -feil.

Løsningen er å fjerne den korrupte krukken fra depotet. La oss se et par måter.

3. Slett Local Repository

En rask løsning for feilen er å slett hele Maven lokale depot og bygg prosjektet igjen:

rm -rf $ {LOCAL_REPOSITORY}

Dette vil slette den lokale hurtigbufferen og laste ned alle prosjektavhengighetene på nytt - ikke veldig effektiv.

Merk at standard lokalt depot er på $ {user.home} /. m2 / repository med mindre vi spesifiserte det i vår settings.xml stikkord. Vi kan også finne det lokale depotet ved kommandoen: mvn help: evaluere -Dexpression = settings.localRepository

4. Finn den korrupte krukken

En annen løsning er å identifiser den spesifikke korrupte krukken og slett den fra det lokale depotet.

Når vi bruker sporingskommandoen Maven output stack, inneholder den korrupte jar-detaljer når den ikke behandler den.

Vi kan aktivere feilsøkingslogging ved å legge til -X til build-kommandoen:

mvn -X pakke

Den resulterende stabelsporingen vil indikere den ødelagte glasset mot slutten av loggen. Etter å ha identifisert den ødelagte glasset, kan vi finne den i det lokale depotet og slette den. Nå ved bygging vil Maven prøve å laste ned glasset på nytt.

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

finn $ {LOCAL_REPOSITORY} -navn "* .jar" | xargs -L 1 glidelås -T | grep-feil

5. Valider kontrollsummer

De to løsningene som er nevnt tidligere, vil bare tvinge Maven til å laste ned glasset på nytt. Selvfølgelig kan problemet oppstå igjen i fremtidige nedlastinger. Vi kan forhindre det ved å konfigurere Maven til å validere kontrollsummen mens du laster ned gjenstanden fra et eksternt lager.

Vi kan legge til –Streng-sjekksummer eller -C alternativet til Maven-kommandoen. Dette vil føre til at Maven mislykkes i byggingen hvis den beregnede kontrollsummen ikke samsvarer med verdien i kontrollsummen.

Det er to alternativer, enten å mislykkes build hvis sjekksummer ikke stemmer overens:

-C, - strenge kontrollsummer

eller varsle som er standardalternativet:

-c, - lax-checksums

I dag krever Maven signaturfilene mens du laster opp gjenstander til det sentrale depotet. Men det kan være gjenstander i det sentrale depotet som ikke har signaturfilene, spesielt de historiske. Derfor er standardalternativet varsle.

For en mer permanent løsning kan vi konfigurere checksumPolicy i Maven's settings.xml fil. Denne egenskapen spesifiserer atferden når bekreftelsen av en gjenstandssum mislykkes. For å unngå problemer i fremtiden, la oss redigere vår settings.xml filen mislykkes i nedlastingen når sjekksummen mislykkes:

    codehausSnapshots Codehaus Snapshots false mislykkes alltid 

Vi trenger selvfølgelig å gjøre dette for hvert av våre konfigurerte arkiver.

6. Konklusjon

I denne raske oppskriften har vi sett når en ugyldig LOC-topptekstfeil kan oppstå, og alternativer for hvordan du skal håndtere den.