streamalism.org

1. Inleiding

Soms wanneer een pot in onze lokale Maven-repo corrupt is, zien we de fout: Ongeldige LOC-koptekst.

In deze tutorial gaan we leren wanneer het gebeurt en hoe we moeten omgaan met en zelfs soms voorkomen.

2. Wanneer komt "Invalid LOC Header" voor?

Maven downloadt de afhankelijkheden van een project naar een bekende locatie op ons bestandssysteem, een lokale repository genaamd. Elk artefact dat Maven downloadt, gaat ook vergezeld van de bijbehorende SHA1- en MD5-checksum-bestanden:

Het doel van deze checksums is om de integriteit van de bijbehorende artefacten te waarborgen. Sinds netwerken en bestandssystemen kunnen falen, net als al het andere, zijn er momenten waarop artefacten beschadigd raken, waardoor de inhoud van het artefact niet overeenkomt met de handtekening.

In deze situaties genereren Maven-builds een "ongeldige LOC-header" -fout.

De oplossing is om de corrupte jar uit de repository te verwijderen. Laten we een paar manieren bekijken.

3. Verwijder de lokale repository

Een snelle oplossing voor de fout is om verwijder de hele lokale Maven-repository en bouw het project opnieuw:

rm -rf $ {LOCAL_REPOSITORY}

Hiermee wordt de lokale cache gewist en worden alle projectafhankelijkheden opnieuw gedownload - niet erg efficiënt.

Merk op dat de standaard lokale repository is op $ {user.home} /. m2 / repository tenzij we het hebben gespecificeerd in onze settings.xml label. We kunnen de lokale repository ook vinden met het commando: mvn help: evalueren -Dexpression = settings.localRepository

4. Zoek de corrupte pot

Een andere oplossing is identificeer de specifieke corrupte jar en verwijder deze uit de lokale repository.

Wanneer we de Maven output stack trace-opdracht gebruiken, bevat deze de corrupte jar-details wanneer deze niet kan worden verwerkt.

We kunnen logboekregistratie op foutopsporingsniveau inschakelen door -X toe te voegen aan de build-opdracht:

mvn -X pakket

De resulterende stacktrace geeft de beschadigde jar aan het einde van het logboek aan. Nadat we de beschadigde jar hebben geïdentificeerd, kunnen we deze in de lokale repository lokaliseren en verwijderen. Nu bij het bouwen, zal Maven opnieuw proberen de jar te downloaden.

We kunnen ook de integriteit van het archief testen met de zip -T opdracht:

zoek $ {LOCAL_REPOSITORY} -naam "* .jar" | xargs -L 1 ritssluiting -T | grep-fout

5. Valideer checksums

De twee eerder genoemde oplossingen zullen Maven alleen dwingen om de jar opnieuw te downloaden. Het probleem kan natuurlijk opnieuw optreden bij toekomstige downloads. We kunnen dat voorkomen door Maven te configureren om de checksum te valideren tijdens het downloaden van het artefact van een externe repository.

We kunnen de –Strikte controlesommen of -C optie voor het Maven-commando. Dit zorgt ervoor dat Maven de build mislukt als de berekende checksum niet overeenkomt met de waarde in checksum-bestanden.

Er zijn twee opties: mislukken de build als checksums niet overeenkomen:

-C, - strikte controlesommen

of waarschuwen wat de standaardoptie is:

-c, - lakse checksums

Tegenwoordig heeft Maven de handtekeningbestanden nodig tijdens het uploaden van artefacten naar de centrale opslagplaats. Maar er kunnen artefacten in de centrale opslagplaats zijn die de handtekeningbestanden niet hebben, vooral de historische. Daarom is de standaardoptie waarschuwen.

Voor een meer permanente oplossing kunnen we configureren checksumPolicy in Maven's settings.xml het dossier. Deze eigenschap specificeert het gedrag wanneer verificatie van een artefactcontrolesom mislukt. Laten we, om problemen in de toekomst te voorkomen, onze settings.xml bestand om de download niet te laten mislukken als de checksum mislukt:

    codehausSnapshots Codehaus-snapshots false mislukken altijd 

We zouden dit natuurlijk moeten doen voor elk van onze geconfigureerde repositories.

6. Conclusie

In dit korte overzicht hebben we gezien wanneer een ongeldige LOC-headerfout kan optreden en hebben we opties voor hoe hiermee om te gaan.