Schnell hingehackt:
Vermutlich macht das gar keinen Sinn, aber … das ist bei mir eine Form der Prokrastination 
1 „Gefällt mir“
Was genau ist denn ein invalid jar?
Jars, die aus irgendeinem Grund nicht vollständig oder sonst wie kaputt sind, z.B. wenn bei deren Download irgendwas schief ging.
Sind ziemlich nervig, weil sie für Maven zwar da sind, beim Kompilieren oder zur Laufzeit aber nicht benutzt werden können.
Aus meiner Sicht genau einmal $HOME/.m2/repository löschen. Dann Checksum Policy anpassen (fail) dann hat sich das erledigt…
Gruß
Karl Heinz
1 „Gefällt mir“
Bei mir hat das Repo lokal 14469 Dateien und 1.25 Gigabyte. Das will ich nicht komplett neu downloaden, nur weil irgendwo eine JAR kaputt ist.
Die passende Websuche zeigt, dass das ein häufiges Problem ist, und die ““Lösung””, die meistens vorgeschlagen wird, ist genau die: Alles löschen und neu drüberbügeln - ohne sicher sein zu können, dass das das Problem löst…
Sicher ist das Tool ein Vorschlaghammer, mit dem eine Nuss geknackt wird (und vielleicht nicht mal das richtig), aber … jetzt weiß ich ein bißchen was über programmatische Maven-Dependency-Resolution *schulternzuck*
Tja das eigentliche Problem ist, dass fast keiner die Checksum policy einschaltet (fail). Das empfehle ich immer wieder. Die Argumentation “Das will ich nicht komplett neu downloaden…” ??? Das ist doch genau der Punkt. Du weißt nicht ob, ob überhaupt und welche jar’s “kaputt” sind…danach bist Du sicher…(BTW: Meins is ca. 3.4 GiB)…
Gruß
Karl Heinz
Das mit der Checksum Policy könntest du jetzt als ca. 2000 Antworten auf stack overflow Fragen posten 
Der Punkt ist: Mit dem Tool werden alle Dependencies für eine POM aufgelistet, und angezeigt, welche „kaputt“ sind (und die Option, das lokale m2 komplett zu scannen, ist schon angedacht). Natürlich ist das weniger „sicher“, als eine echte checksum, aber vielleicht findet’s jemand nützlich…
Ansonsten stellt sich mir die Frage, ob (und wenn nicht: warum nicht?) es nicht sowas gibt wie
mvn dependencies validate
Sooo schwer sollte das ja nicht sein… 
EDIT:
Eben nicht. Irgendwo ist die kaputte JAR ja hergekommen. (Prüft die MC eigentlich, ob JARs geladen werden könnten? D.h. könnte es nicht auch sein, dass eine kaputte JAR in der MC liegt? Hoffentlich kann das nicht passieren…). Selbst wenn man frisch downloadet kann immernoch eine kaputte dabei sein (oder sogar mehr als vorher). Don’t fix what’s not broken 
Ja klar das mit SO könnte ich machen…
mvn dependencies validate
Wenn das nicht so schwer ist…warum produzierst Du nich einfach mal schnell einen Pull Request der das implementiert…
…abgesehen gibt es ja schon die Checksums…somit wäre die Frage was “validate” den prüfen sollte?
Wenn Du die Checksum Policy auf “fail” stellst…wir der Build gebrochen und das JAR auch nicht in Dein lokalen cache abgelegt…Dort ist dann lediglich ein “_.lastUpdated” zu sehen…
In Central gibt es alte JAR’s (sehr alte) die falsche Checksums (bin mir aber nicht sicher) haben wenn vorhanden würden die ja dann eben eine Failure des Builds auslösen…
Den Punkt: “Prüft die MC eigentlich, ob JARs geladen werden könnten” ? verstehe ich nicht? Der Download findet bei Dir auf der Machine statt…
Die eigentliche Frage ist aber: Was verstehst Du unter “kaputtes JAR” ?
Gruß
Karl Heinz
Weil es für jemanden, der noch nie an Maven-Plugins gearbeteit hat, und erstmal „an die richtige Stelle hin-zoomen muss“, aufwändig ist - eben diese Einarbeitung, bis man weiß, wo diese Funktionalität so umgesetzt werden kann, dass es den best practices und Konventionen von Maven-Plugins entspricht.
Das „validate“ würde sicherstellen, was jetzt eben dieses hemdsärmelig runtergehackte Tool sicherstellt: Dass alle JARs, die als Dependency deklariert sind und im lokalen repo liegen, geladen werden können.
Nun, vielleicht ist das nicht ganz klar geworden: Es kommt wohl nicht selten vor (und ich habe das auch schon beobachtet) : Man schreibt eine dependency in seine POM. Maven lädt die dann runter, und in der IDE sieht alles gut aus - d.h. das ganze läßt sich compilieren. Aber beim Start (oder sogar erst zur Laufzeit (!) des Programms) sagt er dann bei irgendeiner Klasse aus irgendeiner JAR: „Invalid LOC header“, und kachelt ab.
Dieser „Invalid LOC header“-Fehler tritt wohl auf, wenn (*händewedel*) beim Download
irgendwas schiefgegangen ist - z.B. irgendein Netzwerkproblem oder so…?
Wenn man das Problem mal hat, kann man alles löschen und ein paar GB neu runterladen (kann OK sein, siehe xkcd: Compiling - genau dafür wurde Docker erfunden 
). Aber wenn einem dafür die Zeit zu schade ist, oder nach dem frischen Download wieder eine JAR einen „Invalid LOC header“ hat, ist das blöd. Die Alternative: DependencyCleaner starten, „Resolve“, „Remove“, „Resolve“ - dann geht’s.
Meine Frage bezog sich darauf, ob man eine JAR in die Maven Central bringen kann, die wirklich (schon dort!) kaputt ist - also nicht geladen werden kann. (So eine JAR könnte ja ggf. dann auch eine Checksum haben, die genau zur kaputten Version der JAR passt…).
Das wird ja schon vorher gemacht eben durch die Checksum (wenn man es denn konfiguriert hat)…geladen werden können bedeutet? Wenn es im lokalen cache liegt ist es geladen worden und somit nutzbar…
In der IDE kann man das auch einstellen sowohl in Eclipse, Netbeans als auch in IDEA IntelliJ…
Wie schon gesagt …das Problem sollte man am Anfang lösen…sprich einmal from scratch sauber aufsetzen…mit checksum policy auf fail…
Wenn ein Jar nach Central geht werden auch für alle Dateien die Prüfsummen mitgenommen… und auch mit hoch geladen…soweit ich informiert bin werden die Prüfsummen auch nochmal gegen die hoch geladenen gecheckt…somit ist es technisch möglich ein JAR hochzuladen, dass dann am Ende ein ungültiges JAR/ZIP darstellt (also sprich einen solche „Invalid LOC header“ produziert)…
BTW: Das hat nichts mit Docker zu tuen…in dem Falle mehr mit CI…
Update: Maven – Maven Security)
„Geladen werden können“ bedeutet, dass die JAR eine gültige JAR ist, die man zumindest mit new JarFile(f) aufmachen kann, ohne dass eine Exception fliegt.
Nochmal: Das Problem ist wohl nicht so selten. Die „Haupt“-Frage auf SO ist die hier: jakarta ee - Deploying Maven project throws java.util.zip.ZipException: invalid LOC header (bad signature) - Stack Overflow Auch dort wird gesagt, dass „alles löschen und neu laden“ eine Option ist, aber auch kommentiert, dass das sehr unpraktisch erscheint.
Interesanterweise wird dort nirgendwo die „Checksum“ erwähnt, d.h. wenn das das Problem löst, sollte man das da wirklich als Antwort posten (und wenn du’s nicht machst, mach’ ich es vielleicht - es ist nur so schwer, zu überprüfen, ob das das Problem wirklich verhindert…)
Den Hinweis auf die „Security“-Seite kann ich gerade nicht einordnen. Das Tool erstellt eine new JarFile(f) - wenn das schon kritisch ist, will ich gar nicht wissen, was passiert, wenn die JVM die JAR „echt“ lädt.
Ich sehe das so:
Einerseits finde ich es nicht gut dass Maven selbst mit checksum policy fail das kaputte Artifact rumliegen laesst, der naechste Build schlaegt dann naemlich auch fehl, bis man das den lokalen Cache manuell loescht, aergerlich bei Build Agents die nach einem defekten download alle folgenden builds bricht, lkar kann man das fuer jeden build neu runterladen, skaliert aber schlecht, zB. mit 200+ Agents per branch builds, hunderte branches, eigentlich sollte es reichen die SNAPSHOTs vor jedem Build zu loeschen, releases sollten sich ja nie aendern…
Anderseits ist ~/.m2/repository eben nur ein Cache der schnell veraltet, regelmaessiges loeschen schadet nicht, zwischen einmal am Tag und einmal die Woche halte ich fuer angemessen, das Argument mit “soviel Download Volumen” sehe ich als ueberholt bei dieser Frequenz, ein Netfix Film bzw. ein paar Folgen einer Serie sind groesser.
Nun, es ist kein „cache“ in diesem Sinne. Es ist ja tatsächlich so, dass das, was da drin steht, NIE veraltet. Es ist kein Cache, sondern ein lokales Repository. Es kommen immer nur neue Sache dazu, aber alte werden nie „ungültig“ (und das ist auch gut so!). Von daher würde ich „relemäßiges Löschen“ (oder die tatsächliche (oder vermeintliche) Notwendigkeit dafür) mit einem 
betrachten…
Es ist nur ein Cache, einmal die settings.xml aendern oder nur ein Projekt bauen welches seine eigenes Repos deklariert, und schon hat man sehr schnell Muell drinnen, regelmaessiges loeschen gehoert IME zu den “standard practices”.
Fuer “Ungueltig” reicht eben schon das man ein OSS Projekt baut welches seine eigenen, “fragwuerdigen” Repos deklariert, das muss nicht immer alles richtig sein…