Run the project with idea today. When you want to package directly, the result is that the packaging fails and an error is always reported   [ERROR] Malformed \uxxxx encoding.

After checking on the Internet, it has been said that there are paths that use errors when using slashes. It’s good to replace “\” with “/”, but there is no “\” in my configuration file and POM file.

In addition, let’s change the Maven warehouse and download the jar package again, but there are a lot of jars in my project, and some jars need to be imported manually. It must be unrealistic to download again with another Maven.

Until I saw an article later, MacOS – java.lang.illegalargumentexception: malformed \ uxxxx encoding while MVN install – stack overflow

The solution given in the article is to find the path to the library in the./m2/folder and delete it.

But

I still don’t have this folder.

Later, I searched the resolver-status.properties file globally using everthing, and found several. And look at the generation time, it was generated in the process of my packaging failure.

When I opened the file, I found that the error information of each package was recorded, and some of them were garbled.

So I deleted all resolver-status.properties generated during my packaging failure,

Then MVN install again with idea, and the project is packaged successfully.

So unify the following online solutions

1. First, check whether there are path errors in the. Properties,. YML, pom.xml, logback and other configurations of the project

2. Update the Maven repository and download the jar package again

3. Delete the path to the library or resolver-status.properties file

In either case, it is recommended to restart the editor. For idea, directly click the invalidate caches/restart button to clean up the cache and restart the idea

Like the second, it is unnecessary to update Maven warehouse. It is not necessary to download all jars again. You can download some jar packages that have not been downloaded successfully again.

How to judge whether the dependent download failed

Generally, unsuccessful downloading of dependencies will generate a file with the suffix not .Lastupdated. Once this file is generated, the dependencies will always fail to download. No matter how to reload Maven warehouse, the download will fail. It seems that when Maven checks the local library and checks the suffix file, it doesn’t seem to download the current dependency again.

Changing the Maven warehouse address is actually a new empty folder. In this way, the dependency will be downloaded again. Changing the dependent version is actually a new empty folder. Because the dependencies of each version will be placed in a separate folder

In this way, deleting files with the suffix .Lastupdated directly eliminates the need to update the Maven warehouse. In this way, successful downloads do not need to be downloaded again.

Of course, sometimes, we don’t know that the dependencies are not downloaded successfully, and only the .Lastupdated file is generated. Then, we can write a bat script to traverse all dependencies under the Maven warehouse, check whether the file suffix is .Lastupdated, and delete it if necessary. After the deletion is completed, use idea reload to the Maven warehouse again to download the dependencies again.

The script is as follows:

@echo off
::REPOSITORY_PATH replace with your own maven address
set REPOSITORY_PATH=D:\data\maven\maven-3.8.1-repository
echo %REPOSITORY_PATH%
for /f "delims=" %%i in ('dir /b /s "%REPOSITORY_PATH%\*lastUpdated*"') do (
    del /s /q %%i
)
pause

1. Create a new TXT file on the desktop, copy the contents above, and replace your Maven warehouse address.

2. Change the suffix of TXT file to. Bat and save the file

3. Double click to run the bat script.

This will delete all the .Lastupdated files in your Maven warehouse, and then you can download the jar package again