1. Introducción
A veces, cuando un jar en nuestro repositorio local de Maven está dañado, veremos el error: Encabezado LOC no válido .
En este tutorial, aprenderemos cuándo sucede y cómo manejarlo e incluso a veces prevenirlo.
2. ¿Cuándo ocurre el "Encabezado LOC no válido"?
Maven descarga las dependencias de un proyecto en una ubicación conocida en nuestro sistema de archivos llamado repositorio local. Cada artefacto que descarga Maven también va acompañado de sus archivos de suma de comprobación SHA1 y MD5:
El propósito de estas sumas de verificación es garantizar la integridad de los artefactos asociados. Dado que las redes y los sistemas de archivos pueden fallar, como cualquier otra cosa, hay momentos en que los artefactos se corrompen, lo que hace que el contenido del artefacto no coincida con la firma.
En estas situaciones, las compilaciones de Maven arrojan un error de "encabezado LOC no válido".
La solución es eliminar el jar corrupto del repositorio. Veamos un par de formas.
3. Eliminar el repositorio local
Una solución rápida para el error es eliminar todo el repositorio local de Maven y volver a compilar el proyecto:
rm -rf ${LOCAL_REPOSITORY}Esto borrará el caché local y volverá a descargar todas las dependencias del proyecto, lo que no es muy eficiente.
Tenga en cuenta que el repositorio local predeterminado está en $ {user.home} /. M2 / repository a menos que lo especifiquemos en nuestra etiqueta settings.xml . También podemos encontrar el repositorio local mediante el comando: mvn help: evaluar -Dexpression = settings.localRepository
4. Encuentra el frasco dañado
Otra solución es identificar el jar corrupto específico y eliminarlo del repositorio local .
Cuando usamos el comando de seguimiento de la pila de salida de Maven, contendrá los detalles del jar corrupto cuando no pueda procesarlo.
Podemos habilitar el registro de nivel de depuración agregando -X al comando de compilación:
mvn -X packageEl seguimiento de la pila resultante indicará el jar dañado hacia el final del registro. Después de identificar el jar dañado, podemos ubicarlo en el repositorio local y eliminarlo. Ahora, tras la compilación, Maven volverá a intentar descargar el tarro.
Además, podemos probar la integridad del archivo con el comando zip -T :
find ${LOCAL_REPOSITORY} -name "*.jar" | xargs -L 1 zip -T | grep error5. Validar sumas de comprobación
Las dos soluciones mencionadas anteriormente solo obligarán a Maven a volver a descargar el jar. Por supuesto, el problema podría volver a ocurrir en futuras descargas. Podemos evitar eso configurando Maven para validar la suma de comprobación mientras descargamos el artefacto desde un repositorio remoto.
Podemos agregar la opción –strict-checksums o -C al comando Maven. Esto hará que Maven falle en la compilación si la suma de comprobación calculada no coincide con el valor de los archivos de suma de comprobación.
Hay dos opciones, para fallar la compilación si las sumas de verificación no coinciden:
-C,--strict-checksumso advertir cuál es la opción predeterminada:
-c,--lax-checksumsHoy en día, Maven requiere los archivos de firmas mientras carga artefactos al repositorio central. Pero puede haber artefactos en el repositorio central que no tengan los archivos de firmas , particularmente los históricos. Es por eso que la opción predeterminada es advertir .
Para una solución más permanente, podemos configurar checksumPolicy en el archivo settings.xml de Maven . Esta propiedad especifica el comportamiento cuando falla la verificación de la suma de comprobación de un artefacto. Para evitar problemas en el futuro, editemos nuestro archivo settings.xml para que falle la descarga cuando falle la suma de comprobación:
codehausSnapshots Codehaus Snapshots false always fail Por supuesto, necesitaríamos hacer esto para cada uno de nuestros repositorios configurados.
6. Conclusión
En este artículo rápido, hemos visto cuándo puede ocurrir un error de encabezado LOC no válido y opciones sobre cómo manejarlo.