[m2e-users] m2e hanging at 65% (aka Aether locking)

["Andi Scharfstein" <andi.scharfstein@xxxxxxxxxx>]

Hello,
we recently introduced m2e for a big legacy system and now are trying to
deal with one issue - it is very slow when running unit tests, which we
don't see on the command line with "mvn test". I'm asking here for help as
a last resort, we already tried various approaches but none so far worked.

This is the scenario:
We are working on a legacy system distributed over ~300 Eclipse projects,
where there are obviously quite a few dependencies. I now want to run a
specific test case in one of the projects, this project has about 45
dependencies overall (even split between JAR dependencies and project
dependencies). Before the test case starts running, m2e spends about 13
seconds hanging at 65% ("Launching"), after that the test is executed as
expected. We are using Eclipse 4.4.2 and m2e 1.6.1.20150625-2338, but we
already tried other releases and the behavior remained consistent. Our
machines are running Windows 7 (64bit).

Profiling Eclipse showed that of the 13 seconds we spent waiting, almost
all of the time was taken up by various calls to
org.apache.maven.project.DefaultProjectBuilder.build(), going to
DefaultProjectBuilder.resolveDependencies() and
DefaultProjectBuilder.initProject() which again uses
resolveDependencies(). In these calls, over 90% of the time was spent just
for io.takari.aether.concurrency.LockingSyncContext to acquire and close
locks. I have observed hundreds of these AETHERLOCK files being created
and deleted again in my Maven repo (which resides on an SSD by the way).

So, I have a number of questions:
- Why does locking take so much time?
- Why is this behavior only visible using m2e, but not pure Maven?
- And most importantly, how do I make it go away?

I would be most grateful for any answers, suggestions or debugging advice.
Naturally I'll gladly answer any clarification questions. I hope this is
the right forum for this questions, please feel free to redirect me to
some other place if that assumption turns out to be misguided.

Thanks in advance
Andi Scharfstein