java.lang.IllegalArgumentException: Fehlerhafte \uxxxx-Kodierung während der mvn-Installation

Lesezeit: 10 Minuten

Beim Ausführen von mvn install in meinem Projekt erhalte ich diesen Fehler. Während viele Antworten und Ressourcen auf Fehler hinweisen / vs \, möchte ich erwähnen, dass ich keine lokalen Änderungen habe und dieses Repo für andere in meinem Team gut funktioniert. Bei mir hat es früher auch gut funktioniert.

Läuft auf Mac OS 10.15.7 mit JDK 1.8.0_291

Bitte finden Sie den vollständigen Stacktrace:

java.lang.IllegalArgumentException: Malformed \uxxxx encoding.
    at java.util.Properties.loadConvert (Properties.java:672)
    at java.util.Properties.load0 (Properties.java:455)
    at java.util.Properties.load (Properties.java:408)
    at org.eclipse.aether.internal.impl.TrackingFileManager.read (TrackingFileManager.java:56)
    at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read (DefaultUpdateCheckManager.java:511)
    at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata (DefaultUpdateCheckManager.java:250)
    at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve (DefaultMetadataResolver.java:302)
    at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata (DefaultMetadataResolver.java:181)
    at org.apache.maven.repository.internal.DefaultVersionRangeResolver.getVersions (DefaultVersionRangeResolver.java:198)
    at org.apache.maven.repository.internal.DefaultVersionRangeResolver.resolveVersionRange (DefaultVersionRangeResolver.java:148)
    at org.apache.maven.repository.internal.DefaultModelResolver.resolveModel (DefaultModelResolver.java:197)
    at org.apache.maven.model.building.DefaultModelBuilder.readParentExternally (DefaultModelBuilder.java:1070)
    at org.apache.maven.model.building.DefaultModelBuilder.readParent (DefaultModelBuilder.java:846)
    at org.apache.maven.model.building.DefaultModelBuilder.build (DefaultModelBuilder.java:337)
    at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom (DefaultArtifactDescriptorReader.java:292)
    at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor (DefaultArtifactDescriptorReader.java:171)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.resolveCachedArtifactDescriptor (DefaultDependencyCollector.java:538)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.getArtifactDescriptorResult (DefaultDependencyCollector.java:523)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:410)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:362)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process (DefaultDependencyCollector.java:349)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse (DefaultDependencyCollector.java:506)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:458)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:362)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process (DefaultDependencyCollector.java:349)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse (DefaultDependencyCollector.java:506)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:458)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:362)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process (DefaultDependencyCollector.java:349)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse (DefaultDependencyCollector.java:506)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:458)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:362)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process (DefaultDependencyCollector.java:349)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse (DefaultDependencyCollector.java:506)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:458)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:362)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process (DefaultDependencyCollector.java:349)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse (DefaultDependencyCollector.java:506)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:458)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:362)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process (DefaultDependencyCollector.java:349)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse (DefaultDependencyCollector.java:506)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:458)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:362)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process (DefaultDependencyCollector.java:349)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse (DefaultDependencyCollector.java:506)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:458)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:362)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process (DefaultDependencyCollector.java:349)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies (DefaultDependencyCollector.java:254)
    at org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies (DefaultRepositorySystem.java:284)
    at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve (DefaultProjectDependenciesResolver.java:169)
    at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies (LifecycleDependencyResolver.java:243)
    at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies (LifecycleDependencyResolver.java:147)
    at org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved (MojoExecutor.java:248)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:202)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:78)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:567)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
[ERROR] 

Folgendes habe ich bereits probiert:

  1. Java auf meinem Mac neu installiert
  2. Maven neu installiert
  3. Es wurde mehrmals versucht, den Cache zu ungültig zu machen und IntelliJ neu zu starten.

  • Ich habe ähnliche Probleme. Alle lokalen Änderungen rückgängig gemacht und das Problem immer noch. Hat heute früher funktioniert und bin mir ziemlich sicher, dass ich keine Updates hatte.

    –Sebastian L

    16. Juni 2021 um 14:33 Uhr

  • @SebastianL Bitte finde meine Antwort, es hat bei mir funktioniert

    – Shylajhaa

    16. Juni 2021 um 16:24 Uhr

Benutzeravatar von Roy van Santen
Roy Van Santen

Für mich stellte sich heraus, dass es sich auch um eine beschädigte Abhängigkeit handelte.
Ich wollte den Prozess der Einrichtung des Debuggers nicht durchlaufen, also entschied ich mich, nach Dateien zu suchen, die enthalten \u0000 in meinem ~/.m2 Verzeichnis durch Ausführen von:

grep -rnw ~/.m2 -e '\u0000'

Danach erhalten Sie die beschädigten Dateien, löschen diese Dateien und erstellen dann den Maven.

Beachten Sie, dass Sie Ihren Repository-Ordner angeben müssen, wenn Sie ihn anders als den Standard konfiguriert haben. Lies dein ~/.m2/settings.xml und verwenden Sie den Wert von localRepository stattdessen. Z.B:

<settings>
  <localRepository>/else/where</localRepository>

verwenden:

grep -rnw /else/where -e '\u0000'

und wenn Sie möchten, dass alle diese Dateien entfernt werden, leiten Sie die Dateinamen an xargs rm:

grep -lrnw /else/where -e '\u0000' | xargs rm

  • Das hat bei mir funktioniert. Unter macOS habe ich “grep -r -e ‘\u0000’ ~/.m2” ausgeführt und es ergab die korrekte resolver-ststus.properties, die nach dem Löschen der Abhängigkeit durch eine korrekte ersetzt wurde und die Dinge funktionierten.

    – Jubz

    24. September 2021 um 10:09 Uhr

  • Ich muss aufpolieren grep Optionen. Das ist prägnanter als das, was ich getan habe: find ~/.m2 -name "resolver-status.properties" -print -exec grep "u0" {} \;

    – triple.vee

    13. Dezember 2021 um 3:30 Uhr


  • Meinen Tag gerettet. Danke für den Tipp!

    – Beethoven

    1. April um 12:37 Uhr

  • Bei mir war es eine der _remote.repositories-Dateien, die kaputt war

    – mvn

    29. April um 12:41 Uhr


  • Falls Leute in Windows Probleme haben, können Sie diesen Befehl im .m2-Verzeichnis ausführen FINDSTR /S /M "u0" resolver-status.properties um beschädigte Dateien zu finden.

    – Manisch Bansal

    9. Juni um 10:24 Uhr

Um herauszufinden, welche Datei fehlerhaft ist (um nicht Ihr gesamtes Maven-Repository löschen zu müssen), können Sie sie folgendermaßen debuggen:

  1. Fügen Sie der entsprechenden Zeile in einen Haltepunkt hinzu java.util.Properties (wie im Fehler-Stack-Trace beschrieben) und führen Sie dann eine beliebige Maven-Aktion im Debug-Modus aus.

Geben Sie hier die Bildbeschreibung ein

  1. Wenn der Code diesen Haltepunkt erreicht, suchen und wählen Sie ihn aus TrackingFileManager.read(File) im Callstack.

Geben Sie hier die Bildbeschreibung ein

  1. Suchen Sie nun den Pfad der Datei, die das Problem verursacht hat.

Geben Sie hier die Bildbeschreibung ein

  1. Die Datei ist tatsächlich fehlerhaft … Löschen Sie die Datei (und Maven wird sie während der nächsten Aktion erneut herunterladen).

Geben Sie hier die Bildbeschreibung ein

  1. Die richtige Datei (nachdem sie gelöscht und erneut heruntergeladen wurde):

Geben Sie hier die Bildbeschreibung ein

  • Dies ist eigentlich eine großartige Antwort mit den schrittweisen Details, um die genaue Datei zu finden. Schritt 1 (Hinzufügen eines Haltepunkts in IntelliJ und Verwenden mit Maven) kann folgendermaßen eingerichtet werden: spin.atomicobject.com/2020/08/20/maven-debugging-intellij

    – Gespenst

    7. Oktober 2021 um 7:30 Uhr

  • Funktioniert nicht, wenn Sie Abhängigkeiten kompiliert haben.

    – Getrübter Coder

    19. Oktober 2021 um 17:05 Uhr

Benutzeravatar von Alexey Poletaev
Alexey Poletaev

In meinem Fall lag das Problem in der Bibliothek des Drittanbieters, in der irgendwie falsche Zeichen gespeichert wurden Resolver-Status.Eigenschaften Datei (Beispiel für falsche Zeile: maven-metadata-nexus-releases.xml.lastUpda\u0000\u0000\....), die sich unter der befindet ~/.m2/repository/path-to-the-library. Entfernen Sie einfach den Ordner mit der Bibliothek und erstellen Sie das Projekt neu.

  • Wie werden diese Dateien beschädigt? Ist es ein Fehler mit mvn oder missbrauche ich mvn so, dass es nicht verwendet werden sollte?

    – Joseph

    22. Oktober 2021 um 13:43 Uhr

  • Ich habe dieses Problem immer wieder!

    – Boris Brodsky

    28. Oktober 2021 um 5:28 Uhr

  • Es scheint ein Fehler in Maven 3.8.1 zu sein. Das Problem trat auch nach dem Löschen der Bibliotheken aus dem lokalen Maven-Repository immer wieder auf. Das Upgrade auf die neueste Version von Maven 3.8.3 und die Neuerstellung mit dieser Version haben das Problem behoben.

    – Madjosz

    3. November 2021 um 10:19 Uhr


Ich habe alle Artefakte aus meinem Verzeichnis ~/.m2 entfernt und mvn build erneut ausgeführt. Diesmal war der Build erfolgreich!

Benutzeravatar von Rafi
Raffi

Eigentlich sind die meisten dieser Antworten richtig, aber ein bisschen unvollständig. Meldung erscheint, weil resolver-status.properties Dateien werden beschädigt und enthalten \u0000, wie in micycles Antwort gezeigt. Manchmal hilft es, beschädigte Dateien zu löschen und den maven-Befehl erneut auszuführen. Manchmal verschwindet das Problem und manchmal nicht. Es stellt sich die Frage, WARUM diese Dateien beschädigt werden. Nun, es scheint, dass Maven einen Fehler im Resolver enthält: https://issues.apache.org/jira/browse/MRESOLVER-216

Es scheint, dass die Synchronisierung mehrerer Threads, die für die Auflösung von Abhängigkeiten verantwortlich sind, unterbrochen ist und unter bestimmten Bedingungen mehrere Threads dasselbe Artefakt auflösen und brechen resolver-status.properties wie von micycle gezeigt.

Falls Ihr Build trotz des Löschens defekter Dateien immer noch nicht erfolgreich abgeschlossen wird, möchten Sie möglicherweise die Resolver-Threads auf einen beschränken. Verwenden Sie dazu die JVM-Eigenschaft:

-Daether.metadataResolver.threads=1

Wenn Sie IntelliJ verwenden, verwenden Sie Idea Settings->Build,Execution,Deployment->Maven->Runner aufstellen VMOptions:

IntelliJ-IDEE 2021.3.1

Nachdem Sie diese Änderung vorgenommen haben, denken Sie daran, defekte Dateien (oder ganze .m2 Verzeichnis), denn sobald die Dateien beschädigt sind, werden sie nicht mehr repariert. Führen Sie dann Ihren Maven-Build erneut aus.

  • Bei mir war es eine der _remote.repositories-Dateien, die kaputt war

    – mvn

    29. April um 12:42 Uhr

Patels Benutzeravatar
Patel

Das Entfernen des .m2-Ordners und das Neuinstallieren der Abhängigkeit hat bei mir funktioniert.

  • Bei mir war es eine der _remote.repositories-Dateien, die kaputt war

    – mvn

    29. April um 12:42 Uhr

kamdzis Benutzeravatar
kamdzi

Das Problem liegt wahrscheinlich in einer Ihrer Abhängigkeiten (wie von Alexey vorgeschlagen). Für mich bestand das Problem darin, die richtige Abhängigkeit zu finden, die die Datei „resolver-status.properties“ beschädigt hat. Was geholfen hat, war das Ausführen von mvn clean install im Debug-Modus (unter Verwendung von Intellig Configuration Debug) und das Einfügen des Endpunkts in Properties.java (die genaue Zeile sollte sich in einem Stacktrace befinden, wenn Sie mit der Option -e oder -X ausführen). Beim Debuggen können Sie leicht feststellen, welche Abhängigkeit beschädigt ist, und nur diese Abhängigkeit anstelle des gesamten .m2-Katalogs entfernen

1436140cookie-checkjava.lang.IllegalArgumentException: Fehlerhafte \uxxxx-Kodierung während der mvn-Installation

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy