Gestione dell'errore di intestazione LOC non valido di Maven

1. Introduzione

A volte, quando un vaso nel nostro repository Maven locale è danneggiato, vedremo l'errore: Intestazione LOC non valida .

In questo tutorial, impareremo quando accade e come gestirlo e talvolta anche prevenirlo.

2. Quando si verifica l '"intestazione LOC non valida"?

Maven scarica le dipendenze di un progetto in una posizione nota sul nostro filesystem chiamata repository locale. Ogni artefatto che Maven scarica è anche accompagnato dai suoi file di checksum SHA1 e MD5:

Lo scopo di questi checksum è garantire l'integrità degli artefatti associati. Poiché reti e file system possono guastarsi, proprio come qualsiasi altra cosa, ci sono momenti in cui gli artefatti vengono danneggiati, rendendo il contenuto dell'artefatto non corrispondente alla firma.

In queste situazioni, le build di Maven generano un errore di "intestazione LOC non valida".

La soluzione è rimuovere il jar danneggiato dal repository. Vediamo un paio di modi.

3. Eliminare l'archivio locale

Una soluzione rapida per l'errore consiste nell'eliminare l'intero repository locale di Maven e creare di nuovo il progetto:

rm -rf ${LOCAL_REPOSITORY}

Questo cancellerà la cache locale e scaricherà nuovamente tutte le dipendenze del progetto - non molto efficiente.

Nota che il repository locale predefinito è $ {user.home} /. M2 / repository a meno che non lo abbiamo specificato nel nostro tag settings.xml . Possiamo anche trovare il repository locale con il comando: mvn help: assess -Dexpression = settings.localRepository

4. Trova il barattolo danneggiato

Un'altra soluzione è identificare il jar corrotto specifico ed eliminarlo dal repository locale .

Quando usiamo il comando Maven output stack trace, conterrà i dettagli del jar danneggiato quando non riesce a elaborarlo.

Possiamo abilitare la registrazione a livello di debug aggiungendo -X al comando build:

mvn -X package

La traccia dello stack risultante indicherà il jar danneggiato verso la fine del registro. Dopo aver identificato il jar danneggiato, possiamo individuarlo nel repository locale ed eliminarlo. Ora, dopo la compilazione, Maven riproverà a scaricare il vaso.

Inoltre, possiamo testare l'integrità dell'archivio con il comando zip -T :

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

5. Convalidare i checksum

Le due soluzioni menzionate in precedenza costringeranno solo Maven a scaricare nuovamente il jar. Ovviamente, il problema potrebbe ripresentarsi nei download futuri. Possiamo impedirlo configurando Maven per convalidare il checksum durante il download del manufatto da un repository remoto.

Possiamo aggiungere l' opzione –strict-checksums o -C al comando Maven. Ciò farà sì che Maven fallisca la compilazione se il checksum calcolato non corrisponde al valore nei file di checksum.

Ci sono due opzioni, per fallire la compilazione se i checksum non corrispondono:

-C,--strict-checksums

o avvisa qual è l'opzione predefinita:

-c,--lax-checksums

Oggi Maven richiede i file di firma durante il caricamento degli artefatti nel repository centrale. Ma potrebbero esserci artefatti nel repository centrale che non hanno i file delle firme , in particolare quelli storici. Ecco perché l'opzione predefinita è warn .

Per una soluzione più permanente, possiamo configurare checksumPolicy nel file settings.xml di Maven . Questa proprietà specifica il comportamento quando la verifica di un checksum di un artefatto non riesce. Per evitare problemi in futuro, modifichiamo il nostro file settings.xml per non riuscire il download quando il checksum fallisce:

    codehausSnapshots Codehaus Snapshots  false always fail     

Ovviamente dovremmo farlo per ciascuno dei nostri repository configurati.

6. Conclusione

In questo breve articolo, abbiamo visto quando può verificarsi un errore di intestazione LOC non valido e le opzioni su come gestirlo.