Discussion :

[grunt2000]

Bonjour,

Hier, intrigué par quelques erreurs de compilation inattendues qui annoncent qu'une classe n'est pas trouvée dans un package où elle doit être, je constate qu'un artefact téléchargé est invalide.
Je le détruis. Il est re-téléchargé correctement, et me voici sorti d'affaire.

Sauf si mon dépôt local en contient d'autres, comme ça.
Parce que j'ai peut-être contacté un repository distant dans ses mauvais jours.

Bien sûr, je pourrais supprimer l'intégralité de mon dépôt local et le faire retélécharger entièrement. C'est parfois sain !
Mais foncièrement, ça ne me garantit rien. Sur 100 que je retéléchargerait, 5 (peut-être différents !) seront peut-être endommagés à leur tour...

Maven propose t-il des commandes pour vérifier que les artefacts sont en bon état ?
1) Par simple contrôle local sur .m2,
2) En se connectant de nouveau aux repositories où il a pris les artefacts précédemment ?

Merci !

[tchize_]

Les repository que tu as contacté ont-t-il des md5 associés aux artefacts? Normalement maven devrait comparer le md5 présent sur le repository avec le calcul de la md5 du jar après télépchargement et avant de mettre dans son cache.


Sinon, le plus simple est d'agit quand tu constate le problème. C'est un peu embêtant, mais par expérience, c'est un problème assez rare, ça m'arrive peut être une fois par an de tomber là dessus en utilisant maven tous les jours.

Si tu es dans une société, mettre en place un repository proxy genre nexus peut aussi éviter ce genre de problème.

[grunt2000]

Sur mon repo local, je en vois que des sha1.
La rareté du problème est contrebalancée par la difficulté à le détecter.
Il peut rester invisible un certain temps, faire planter par une classe manquante un programme très tardivement dans son exécution,
voire simplement changer son comportement, ce qui est très sournois. Un convertisseur d'image m'a fait le coup une fois :
il convertissait des images format a en b sans problèmes, mais de a en c, n'y parvenait anormalement pas, sans raison apparente. Et c'était cela.

J'espérais que Maven embarquerait lui-même une commande de contrôle,
car j'ai 1 100 jar dans mon dépôt local, et aussi rare que soit la corruption, c'est malgré tout la cinquième ou sixième fois que je la rencontre en quinze ans de développement Java,
j'aimerais être sûr que tout mon dépôt local est droit, car maintenant j'ai perdu ma confiance en lui.
mais si ce n'est pas le cas, tant pis.

Les dépôts d'artefact Nexus, Artifactory, Archiva sont biens, mais ils ne sont pas des garanties à eux tous seuls.
Il y a peu, j'ai été confronté à un Artifactory qui endommageait lui-même ce qui était sous sa garde !

[tchize_]

normalement si le developpeur a publié le .jar avec un .md5, maven devrait le controller. Maintenant on n'est pas non plus à l'abris d'un artefact corrompu en amont. Et il n'y a pas vraiment moyen de detecter des jar corrompus je pense.

[grunt2000]

Humm, là je suis dans une crise de delirium avec soit Eclipse en cause, soit un anti-virus, soit les dépôts,
mais ma dernière compilation est venu chercher des nouveau artifacts sur Internet, et boum !

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.996 s
[INFO] Finished at: 2017-12-17T18:10:25+01:00
[INFO] Final Memory: 50M/981M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project application-metier-et-gestion: Compilation failure: Compilation failure:
[ERROR] error reading C:\Users\SEVEN\.m2\repository\org\apache\spark\spark-core_2.11\2.2.1\spark-core_2.11-2.2.1.jar; invalid LOC header (bad signature)
[ERROR] error reading C:\Users\SEVEN\.m2\repository\org\apache\hadoop\hadoop-common\2.6.5\hadoop-common-2.6.5.jar; invalid LOC header (bad signature)
[ERROR] error reading C:\Users\SEVEN\.m2\repository\commons-httpclient\commons-httpclient\3.1\commons-httpclient-3.1.jar; invalid LOC header (bad signature)
[ERROR] error reading C:\Users\SEVEN\.m2\repository\commons-configuration\commons-configuration\1.6\commons-configuration-1.6.jar; invalid LOC header (bad signature)
[ERROR] error reading C:\Users\SEVEN\.m2\repository\org\apache\hadoop\hadoop-hdfs\2.6.5\hadoop-hdfs-2.6.5.jar; invalid LOC header (bad signature)
[ERROR] error reading C:\Users\SEVEN\.m2\repository\org\apache\hadoop\hadoop-yarn-api\2.6.5\hadoop-yarn-api-2.6.5.jar; invalid LOC header (bad signature)
[ERROR] error reading C:\Users\SEVEN\.m2\repository\org\apache\spark\spark-network-common_2.11\2.2.1\spark-network-common_2.11-2.2.1.jar; invalid LOC header (bad signature)
[ERROR] error reading C:\Users\SEVEN\.m2\repository\org\fusesource\leveldbjni\leveldbjni-all\1.8\leveldbjni-all-1.8.jar; invalid LOC header (bad signature)
[ERROR] error reading C:\Users\SEVEN\.m2\repository\net\java\dev\jets3t\jets3t\0.9.3\jets3t-0.9.3.jar; invalid LOC header (bad signature)
[ERROR] error reading C:\Users\SEVEN\.m2\repository\org\bouncycastle\bcprov-jdk15on\1.51\bcprov-jdk15on-1.51.jar; invalid stored block lengths
[ERROR] error reading C:\Users\SEVEN\.m2\repository\org\apache\spark\spark-sql_2.11\2.2.1\spark-sql_2.11-2.2.1.jar; invalid LOC header (bad signature)
[ERROR] error reading C:\Users\SEVEN\.m2\repository\org\apache\spark\spark-catalyst_2.11\2.2.1\spark-catalyst_2.11-2.2.1.jar; invalid LOC header (bad signature)
[ERROR] error reading C:\Users\SEVEN\.m2\repository\org\codehaus\janino\janino\2.7.8\janino-2.7.8.jar; invalid LOC header (bad signature)
[ERROR] error reading C:\Users\SEVEN\.m2\repository\org\antlr\antlr4-runtime\4.5.3\antlr4-runtime-4.5.3.jar; invalid LOC header (bad signature)
[ERROR] error reading C:\Users\SEVEN\.m2\repository\org\apache\parquet\parquet-column\1.8.2\parquet-column-1.8.2.jar; invalid LOC header (bad signature)
[ERROR] error reading C:\Users\SEVEN\.m2\repository\org\apache\parquet\parquet-hadoop\1.8.2\parquet-hadoop-1.8.2.jar; invalid LOC header (bad signature)

À priori, c'est l'Eclipse Oxygen qui prend le gaz. Quand je les efface et que je passe en ligne de commande maven, ça les re-télécharge bien.
La soirée commence bien...

[tchize_]

Il y a quoi dans ces fichiers?

Il est possible que tu aie configuré eclipse avec un dépot différent, qui soit le responsable de tes problèmes.

[grunt2000]

Là, je ne le sais plus car j'ai détruit tout mon .m2
Je suis à mon domicile, je n'ai pas de config spéciale.

En conséquence, j'ai forcé le Maven d'Eclipse en offline pour le moment,
et s'il manque des dépendances, c'est Maven en ligne de commande qui ira les chercher.

[Mickael_Istria]

En fait, quand tu vois ces messages dans la console Eclipse IDE, ce n'est pas une erreur Eclipse IDE mais une erreur Maven. Donc si ton Maven que lance Eclipse IDE ne se comporte pas pareil que celui qui est en CLI, le plus probable peut etre par exemple que tu n'utilises pas le meme executable `mvn` (ou meme Java).
Dans la fenetre de Preferences d'Eclipse IDE, regarde les differentes pages a propos de Maven et de Java et verifie que tu utilises bien la meme chose qu'en CLI.

[grunt2000]

Oui, c'est vrai...
En regardant le Maven utilisé par Eclipse, c'est un 3.3.9 embedded.
En externe, j'utilise un 3.5.0. Je fais aller Eclipse dessus aussi. Bonne idée.

Je n'ai pas pris la version 3.5.2 de Maven :
Depuis la 3.5.0, ils veulent mettre des couleurs sur la console, et je ne suis pas contre : c'est plus joyeux.
Mais dans la 3.5.2, ils ont fait une régression moche, et au lieu de couleurs ce sont des caractères parasites qui s'invitent,
sur certaines consoles, dont Git Bash sous Windows.

[tchize_]

En fait, quand tu vois ces messages dans la console Eclipse IDE, ce n'est pas une erreur Eclipse IDE mais une erreur Maven. Donc si ton Maven que lance Eclipse IDE ne se comporte pas pareil que celui qui est en CLI, le plus probable peut etre par exemple que tu n'utilises pas le meme executable `mvn` (ou meme Java).

Ou qu'il y aie bel et bien un bug dans eclipse. Eclipse n'utilise pas l'exécutable maven, mais juste ses librairies, intégrées dans une plugin maven. Donc ce n'est pas 100% le même comportement.
En l'occurence, si je comprends bien ce report https://bugs.eclipse.org/bugs/show_bug.cgi?id=514691 eclipse a la facheuse tendance à lancer plusieurs mvn en parallèle pour récupérer les artefacts et comme maven n'a jamais été thread safe à ce sujet, ça peux corrompre des artefacts si plusieurs threads téléchargent le même en parallèle.

[Mickael_Istria]

Eclipse n'utilise pas l'exécutable maven, mais juste ses librairies, intégrées dans une plugin maven. Donc ce n'est pas 100% le même comportement.

Quand tu vois la stack Maven dans la console, c'est tres generalement qu'il a utilise l'executable.
Mais en effet, c'est possible qu'en amont, avant de lancer l'executable, https://bugs.eclipse.org/bugs/show_bug.cgi?id=514691 se soit produit (et que le resultat est bel et bien un lot de jars corrompus).

[tchize_]

maven embedded est bien juste une librairie. Il n'y a pas de process externe à ma connaissance. Mais je peux me tromper