Why is Eclipse hanging at 57% with the status “Ver

问题:

After recently converting to Maven from Ant, run configurations that launched immediately pre-Maven take an excessive amount of time and consume an abnormal amount of resources while Eclipse prepares to launch the projects.

Eclipse shows this status message:

Verifying launch attributes...

At 57% completion, Eclipse hangs for several minutes before finally launching the run configuration. Once launched, the project runs fine and without a problem.

I found this blog article that suggested to clean the local workspace, but that did not solve the problem, especially considering the author is using Git and I am not.

I am only using the latest m2e maven plugin, with the latest version of Eclipse.

What is causing Eclipse to block when launching these run configurations, and how can I fix it?

回答1:

I had the same symptoms. I could fix it by adjusting

Eclipse -> Preferences -> Maven -> User Settings

My maven user settings file was stored on a remote folder. After moving the file to a local disk, the test now start instantly again.

回答2:

I know this is a rather old question, but I've been having this issue for a while now and none of the solutions found online seemed to work:

• Disable IPv6: didn't work
• Disable Ivy classpath resolution: not applicable
• Moving the maven settings: not applicable
• Delete src classpathentry's from .classpath: this removes all source folders from Eclipse

I did eventually found out (somehow) that having duplicate .classpath files in your workspace can cause serious issues. When importing a multi-module maven project you can easily do this by importing all your modules and your master module (the pom-type module). Doing so, you effectively import everything twice. Closing this master module in Eclipse solved the issue for me. Another workaround would be to not rely on m2eclipse and to use mvn eclipse:eclipse and then import your projects as an 'existing project'.

回答3:

This could be caused by duplicate / erroneous entries in the project's .classpath file. These entries are not necessary, as the maven plugin will take care of properly setting the classpath to launch your project.

To prevent Eclipse from hanging, open all of the referenced projects' .classpath files, which should be in the root directory of the project.

Remove all of the entries who have src as their kind attribute value.

For example:

<classpathentry kind="src" path="src"/>

Once all of these entries are removed, Eclipse will now launch your project instantly.

回答4:

Unfortunately the progress information of the launching in Eclipse is not very accurate. The value of 57% is where all the hard work happens (see e.g. bug 354338).

If you are launching an Eclipse Application or JUnit Plug-in Tests, make sure you have the following plug-ins in your target platform:

• org.junit
• org.eclipse.jdt.junit.runtime
• org.eclipse.jdt.junit4.runtime
• org.eclipse.pde.junit.runtime

Otherwise Eclipse will search the whole p2 cache (in my case over 6000 plug-in jars, takes > 5min) for those plug-ins.

回答5:

I found this way to avoid 'verifying launch attributes... 57%' in Eclipse-Luna-SR2

1. have the launch configuration and the main class in different projects

2. delete the following line from the launch configuration:

   <stringAttribute key="org.eclipse.jdt.launching.CLASSPATH_PROVIDER" value="org.eclipse.m2e.launchconfig.classpathProvider"/>
   

回答6:

With eclipse 2018-12 I had a delay of about 10 seconds at "57%, verifying launch attributes" for every start of a main class or a junit test. I used the windows tool "procMon" to identify about 500.000 failed accesses to jars in this period that I don't have in my classpath. I found those jar references inside the Manifest "Class-Path" entry of many jars I use. After removing the Class-Path entry from all jars the delay now is only 1 second!

Some jars were signed. Then I had to remove the signature files (META-INF/*.SF|*.DSA|*.RSA|*.EC) from the jar, too.

回答7:

One thing that makes a huge difference is how you tell Eclipse what tests you want to run.

When specifying the project name, our tests could take more than 5 minutes to be discovered (the 57%).

If we rather specify the directory containing the test source files, we are down to less than 30 seconds.