Repository navigation
Retire 1.0 migration or move to a Job as this currently locks the UI thread for ~600 ms #2237
Description
Duplicate check
- I have searched for existing issues/discussions and could not find a duplicate.
What happened?
I traced Eclipse as described here (no AI): https://www.vogella.com/tutorials/EclipsePerformance/article.html#sampling-a-full-ide-startup-on-linux
Sampling (thread dumps every 50 ms) shows the UI thread BLOCKED for ~600 ms while the workbench menus are built.
Eclipse SDK I-build 2026-09-03, m2e.core 2.7.800, m2e.core.ui 2.4.201.
"main" BLOCKED, waiting to lock <0x6a9019d70> (MavenImpl$MavenSettings)
MavenImpl$MavenSettings.getSettings(MavenImpl.java:1130)
MavenImpl.getLocalRepositoryPath(MavenImpl.java:186)
RepositoryRegistry.getLocalRepository(RepositoryRegistry.java:328)
M2EUIPluginActivator.start(M2EUIPluginActivator.java:118)
... EclipseLazyStarter.postFindLocalClass
PropertyTesterDescriptor.instantiate
ContributionRecord.computeVisibility
lock holder: "Worker-N" RepositoryRegistryUpdateJob
MavenImpl$MavenSettings.getSettings(MavenImpl.java:1164) - locked <0x6a9019d70>
PlexusContainerManager.newPlexusContainer(PlexusContainerManager.java:239)
Guice.createInjector
M2EUIPluginActivator.startcallsgetRepositoryRegistry().getLocalRepository just to find a legacy .cache/m2e/ directory.
That enters the Maven settings lock held by RepositoryRegistryUpdateJob while Guice builds the Plexus container, so the UI thread waits for the whole container creation.
Suggested fix: drop the legacy cache cleanup (the code already saysTODO: can be removed when some time has passed) or move it into a job.
Steps to reproduce / minimal project
Run the setup as descripted in https://www.vogella.com/tutorials/EclipsePerformance/article.html#sampling-a-full-ide-startup-on-linux
m2e version
m2e.core 2.7.800, m2e.core.ui 2.4.20
Environment (OS, JDK, Eclipse/Maven version)
Ubuntu latest
Was an AI/GenAI agent used to prepare this issue?
Yes, for spellcheck and formating, and I have reviewed all content above for accuracy
Activity
laeubi commentedon Sep 4, 2026
If you look at the stacktrace, this involves a property tester so there is nothing much m2e can do here generally as a property tester can't be lazy. So to tackle such things generally if one wants to improve that part, it would require a change in Eclipse platform first.
For this particular case, delay it into a job sounds reasonable, but I doubt it helps much as then maybe some other code will access (and get blocked) by the settings - so this is a general trade-off at the Eclipse lazy init of bundles, you have to pay the price once (and here just a bit later).
So the more interesting question for me would be, why does the building of the menu ever activates anything here during startup (where the menu is obviously not shown at all?
vogella commentedon Sep 4, 2026
menu has `test forcePluginActivation="true" property="org.eclipse.m2e.hasMavenNature" in its visibleWhen. So your menu does the forcePluginActivation, nothing from platform. I don't know if that is necessary for m2e to work out its visibility for the menus.
Job or delete the code? The comment from @HannesWell in 2022 sounds like it can also be deleted. Its been almost 4 years.
laeubi commentedon Sep 4, 2026
Still none of these menus is actually visible at startup time so there is no point in evaluate any
visibleWhenduring this phase and it actually makes lazy-activation pointless if it is the case.vogella commentedon Sep 4, 2026
I would think so too. So we have two potential improvements, delete migration code / put to job and remove the forceActivation.
laeubi commentedon Sep 4, 2026
No... as said platform should not evaluate
visibleWhenfor menus that are not shown. And as at startup no menu is ever shown it consequently should not activate m2e (regardless of settings).[-]Project menu forces m2e UI activation during startup, blocking the UI thread for ~600 ms[/-][+]Retire 1.0 migration or move to a Job as this currently locks the UI thread for ~600 ms[/+]akurtakov commentedon Nov 6, 2026
Let's get back to m2e side - is there any reason to still keep this migration code?
HannesWell commentedon Nov 8, 2026
No. Created