Gestion d'une erreur d'en-tête LOC non valide Maven

1. Introduction

Parfois, lorsqu'un fichier jar de notre dépôt Maven local est corrompu, nous verrons l'erreur: En-tête LOC non valide .

Dans ce tutoriel, nous allons apprendre quand cela se produit et comment le gérer et même parfois l'empêcher.

2. Quand se produit «En-tête LOC non valide»?

Maven télécharge les dépendances d'un projet dans un emplacement connu de notre système de fichiers appelé référentiel local. Chaque artefact téléchargé par Maven est également accompagné de ses fichiers de somme de contrôle SHA1 et MD5:

Le but de ces sommes de contrôle est d'assurer l'intégrité des artefacts associés. Comme les réseaux et les systèmes de fichiers peuvent échouer, comme toute autre chose, il arrive que des artefacts soient corrompus, ce qui rend le contenu de l'artefact ne correspondant pas à la signature.

Dans ces situations, les builds Maven lancent une erreur «en-tête LOC invalide».

La solution consiste à supprimer le fichier jar corrompu du référentiel. Voyons quelques façons.

3. Supprimez le référentiel local

Une solution rapide à l'erreur consiste à supprimer tout le référentiel local Maven et à reconstruire le projet:

rm -rf ${LOCAL_REPOSITORY}

Cela effacera le cache local et téléchargera à nouveau toutes les dépendances du projet - pas très efficace.

Notez que le dépôt local par défaut est à $ {user.home} /. M2 / repository sauf si nous l'avons spécifié dans notre balise settings.xml . On peut également trouver le référentiel local par la commande: mvn help: evaluer -Dexpression = settings.localRepository

4. Trouvez le pot corrompu

Une autre solution consiste à identifier le fichier jar corrompu spécifique et à le supprimer du référentiel local .

Lorsque nous utilisons la commande de trace de la pile de sortie Maven, elle contient les détails du fichier jar corrompu lorsqu'il ne parvient pas à le traiter.

Nous pouvons activer la journalisation au niveau de débogage en ajoutant -X à la commande build:

mvn -X package

La trace de pile résultante indiquera le fichier jar corrompu vers la fin du journal. Après avoir identifié le fichier jar corrompu, nous pouvons le localiser dans le référentiel local et le supprimer. Maintenant, après la construction, Maven va réessayer de télécharger le fichier jar.

De plus, nous pouvons tester l'intégrité de l'archive avec la commande zip -T :

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

5. Valider les sommes de contrôle

Les deux solutions mentionnées précédemment ne feront que forcer Maven à retélécharger le fichier jar. Bien sûr, le problème pourrait se reproduire lors de futurs téléchargements. Nous pouvons éviter cela en configurant Maven pour valider la somme de contrôle lors du téléchargement de l'artefact à partir d'un référentiel distant.

Nous pouvons ajouter l' option –strict-checksums ou -C à la commande Maven. Cela entraînera l'échec de la construction de Maven si la somme de contrôle calculée ne correspond pas à la valeur des fichiers de somme de contrôle.

Il existe deux options, soit pour échouer la compilation si les sommes de contrôle ne correspondent pas:

-C,--strict-checksums

ou avertir quelle est l'option par défaut:

-c,--lax-checksums

Aujourd'hui, Maven a besoin des fichiers de signature lors du téléchargement des artefacts dans le référentiel central. Mais il peut y avoir des artefacts dans le référentiel central qui ne contiennent pas les fichiers de signature , en particulier les fichiers historiques. C'est pourquoi l'option par défaut est warn .

Pour une solution plus permanente, nous pouvons configurer checksumPolicy dans le fichier settings.xml de Maven . Cette propriété spécifie le comportement en cas d'échec de la vérification d'une somme de contrôle d'artefact. Pour éviter des problèmes à l'avenir, modifions notre fichier settings.xml pour que le téléchargement échoue lorsque la somme de contrôle échoue:

    codehausSnapshots Codehaus Snapshots  false always fail     

Nous aurions bien sûr besoin de le faire pour chacun de nos référentiels configurés.

6. Conclusion

Dans cet article rapide, nous avons vu quand une erreur d'en-tête LOC non valide peut se produire et des options pour la gérer.