M2Eclipse gets stuck in endless update loop

[laeubi]

This has been reported in the following Bugs but its unclear how to reproduce this yet:

• https://bugs.eclipse.org/bugs/show_bug.cgi?id=558317
• https://bugs.eclipse.org/bugs/show_bug.cgi?id=567959
• https://bugs.eclipse.org/bugs/show_bug.cgi?id=553432
• https://bugs.eclipse.org/bugs/show_bug.cgi?id=558689
• https://bugs.eclipse.org/bugs/show_bug.cgi?id=563140

[DieterMai]

I closed ticket Bug 563140 [1] since no longer reproducible

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=563140

[HannesWell]

Is there any progress on this issue? I run into it in my Tycho-Dev workspace (provisioned using the Tycho Oomph-Setup), using Eclipse-for-Commiter latest (currently at 2021-03) and m2e 1.17.2.

I sampled my Dev-Eclipse using VisualVM and from this it looks like the loop is in the LifecycleMappingFactory.

[laeubi]

@HannesWell Good idea. The problem is that this not occurs always, sometimes it helps to update one or two projects. then it works for some time and then comes back. I'm currently also again caught in an endless circle 👎

[HannesWell]

Yes this issue just appeared recently to me. I could make it work once by updating one or two projects as you said. But now this also did not work. It is just terribly annoying, I can hardly change a line of code in my Tycho-Dev workspace.

Anyway. I just attached a debugger and my first impression is that the DependencyResolutionContext passed to the ProjectRegistryManager.refresh method gets always new elements added when refreshPhase2 is called. But I will investigate further.

[laeubi]

ProjectRegistryManager line 504 a new facade is created but I can't tell from the code if this is intentional.

[laeubi]

@mickaelistria can you take a look at this? even worse now my IDE constantly get stuck and I need to kill the process :-(

[laeubi]

One think that might help here:
If I understand the code right, it triggers some kind of "project changed", maybe it would be better to just note all projects that require such a change event in a list, complete the cycle and then trigger one big "project(s) change" event afterwards?

[HannesWell]

Now that I used my Tycho-Dev workspace from an Eclipse instance that is launched (in debug mode) from another Eclipse having the m2e projects in its workspace the endless loop is gone. Even when I use the workspace from the standalone Eclipse again.

When I just hat the debugger attached I observed that constantly pom-files are added to the DependencyResolutionContext context in the very end (line 607) of ProjectRegistryManager.refreshPhase2() by calling context.forcePomFiles(...). Since the calling method runs in a loop while context is not empty this would explain the endlessness.

    Set<RequiredCapability> oldRequirements = newState.setRequirements(pom, requirements);
    if(originalRequirements.containsKey(pom)) {
      oldRequirements = originalRequirements.get(pom);
    }
    // if our dependencies changed, recalculate everyone who depends on us
    // this is needed to deal with transitive dependency resolution in maven
    if(oldCapabilities != null && hasDiff(oldRequirements, requirements)) {
      for(Capability capability : oldCapabilities) {
        context.forcePomFiles(newState.getVersionedDependents(capability, true));
      }
    }

From the relevant code snippet above I concluded that the pom files are only added to the context if hasDiff(oldRequirements, requirements) is true. When I looked into the elements of both sets I noticed that they contain the same artifacts but with different versions. Some were Tycho 2.2.0 some were 2.3.0 and some were 2.4.0-SNAPSHOT (not necessarily mixed in one set but in different hits of the same break-point).
This also coincides with my observation that the endless loop first occurred for me when I fetched and rebased the commits for the Tycho 2.3.0 release from the Tycho git repo. So the modules in my workspace went from 2.3.0-SNAPSHOT to 2.3.0, to 2.4.0-SNAPSHOT. Maybe m2e does not update the project-data correctly and holds some old version strings.

But this is the first time I look into the sources of m2e so this might be the wrong path.

Similar to @laeubi's suggestion I thought that the DependencyResolutionContext should also hold a second set of already refreshed/handled poms in order to avoid the endless loop. Nevertheless the root cause of the endless loop should be found because it seems to work before/sometime.

[mickaelistria]

I don't think I'll be available to work on this issue soon (no more school for my kid here, so reduced productivity and another kid to get born sometimes this month making me off from work for one month); but it's definitely something I'm interested in seeing fixed.
What I have missed the most so far are steps to reproduce from a simpler project. If someone can identify some steps, that would be help in making more concrete progress.
The current depedency resolution in m2e is not immune to build cycles as far as I know. As a consequence, if Tycho has some build cycle it can make things fail. I don't think Tycho has a build cycle but Tycho x.y.0-SNAPSHOT usually builds some parts with Tycho x.y-1.0-SNAPSHOTs, so if versions are ignored or erroneous as suggested by @HannesWell , then it can create a cycle and make resolution fail.

[laeubi]

The problem is that the error comes and goes and when its gone there is normally no demand to broke it again ... my hope is, that maybe someone with more knowledge of this resolving stuff can give a hint or has an idea what could be the issue so for example so its easier to try out for people having the issue than starting from scratch. But I can of course understand that this is not a top-issue as long as it is not reproducible.

What would be of major interest for me would be: How good is this area covered by unit test? So if I start hacking on his, how big is the chance to break something unintentionally and uncovered?

[HannesWell]

Mickeal then all the best for your family.

A reproducible case would indeed be a goo thing. I deleted and re-provisioned my tycho-workspace a few days ago because of this problem and run again into the endless loop (I think it was after going back and forth in the git history between and after the 2.3.0 release). So I can try to find steps to reliably reproduce this issue.

Regarding cycles in the build path: Sometimes I get problem markers indicating cycles in the build path. The last time the vanished by cleaning and building the entire workspace so maybe this was based on outdated metadata that cause the same problem here.

[laeubi]

For the tycho case I was able to break the cycle by:

1. kill all background work (needed to go to prefrences > show systemsleeping and system operation)
2. select tycho-core project > Update Maven Project
3. Now the endless build is gone but I haven't yet tried to update all maven projects

[laeubi]

Below there is an extract from the log, while for some times there are some items different after a while the following entries are repeated over and over again:

10.04.21, 06:32:55 MESZ: [INFO] Resolving P/tycho-metadata-model: org.eclipse.tycho:tycho-metadata-model:2.4.0-SNAPSHOT with classifier  to /tycho-metadata-model/target/classes
10.04.21, 06:32:55 MESZ: [INFO] Resolving P/tycho-embedder-api: org.eclipse.tycho:tycho-embedder-api:2.4.0-SNAPSHOT with classifier  to /tycho-embedder-api/target/classes
10.04.21, 06:32:55 MESZ: [INFO] Resolving P/org.eclipse.tycho.embedder.shared: org.eclipse.tycho:org.eclipse.tycho.embedder.shared:2.4.0-SNAPSHOT with classifier  to /org.eclipse.tycho.embedder.shared/target/classes
10.04.21, 06:32:55 MESZ: [INFO] Resolving P/org.eclipse.tycho.core.shared: org.eclipse.tycho:org.eclipse.tycho.core.shared:2.4.0-SNAPSHOT with classifier  to /org.eclipse.tycho.core.shared/target/classes
10.04.21, 06:32:55 MESZ: [INFO] Resolving P/tycho-lib-detector: org.eclipse.tycho:tycho-lib-detector:2.4.0-SNAPSHOT with classifier  to /tycho-lib-detector/target/classes
10.04.21, 06:32:55 MESZ: [INFO] Using org.eclipse.m2e.jdt.JarLifecycleMapping lifecycle mapping for MavenProject: org.eclipse.tycho:sisu-equinox-launching:2.4.0-SNAPSHOT @ /home/christoph/git/laeubi/tycho/sisu-equinox/sisu-equinox-launching/pom.xml.
10.04.21, 06:32:55 MESZ: [INFO] Resolving P/tycho-core: org.eclipse.tycho:tycho-core:2.4.0-SNAPSHOT with classifier  to /tycho-core/target/classes
10.04.21, 06:32:55 MESZ: [INFO] Resolving P/org.eclipse.tycho.p2.tools.shared: org.eclipse.tycho:org.eclipse.tycho.p2.tools.shared:2.4.0-SNAPSHOT with classifier  to /org.eclipse.tycho.p2.tools.shared/target/classes
10.04.21, 06:32:55 MESZ: [INFO] Resolving P/org.eclipse.tycho.p2.resolver.shared: org.eclipse.tycho:org.eclipse.tycho.p2.resolver.shared:2.4.0-SNAPSHOT with classifier  to /org.eclipse.tycho.p2.resolver.shared/target/classes
10.04.21, 06:32:55 MESZ: [INFO] Resolving P/sisu-equinox-embedder: org.eclipse.tycho:sisu-equinox-embedder:2.4.0-SNAPSHOT with classifier  to /sisu-equinox-embedder/target/classes
10.04.21, 06:32:55 MESZ: [INFO] Resolving P/tycho-metadata-model: org.eclipse.tycho:tycho-metadata-model:2.4.0-SNAPSHOT with classifier  to /tycho-metadata-model/target/classes
10.04.21, 06:32:55 MESZ: [INFO] Resolving P/tycho-embedder-api: org.eclipse.tycho:tycho-embedder-api:2.4.0-SNAPSHOT with classifier  to /tycho-embedder-api/target/classes
10.04.21, 06:32:55 MESZ: [INFO] Resolving P/org.eclipse.tycho.embedder.shared: org.eclipse.tycho:org.eclipse.tycho.embedder.shared:2.4.0-SNAPSHOT with classifier  to /org.eclipse.tycho.embedder.shared/target/classes
10.04.21, 06:32:55 MESZ: [INFO] Resolving P/org.eclipse.tycho.core.shared: org.eclipse.tycho:org.eclipse.tycho.core.shared:2.4.0-SNAPSHOT with classifier  to /org.eclipse.tycho.core.shared/target/classes
10.04.21, 06:32:55 MESZ: [INFO] Resolving P/sisu-equinox-api: org.eclipse.tycho:sisu-equinox-api:2.4.0-SNAPSHOT with classifier  to /sisu-equinox-api/target/classes

I then cancel the job and if I update the 'org.eclipse.tycho:sisu-equinox-api' for example as a singel project it works.

After that I got to Maven > update project, deselect all projects and use "add out of date" then everything works fine. So this seems to happen if

1. All or a set of problematic projects are out of date (this happend for me after switching branches for example)
2. m2e automatically (or manually) tries to update the projects

[laeubi]

I now get an error marker:
Description Resource Path Location Type
The project cannot be built until its prerequisite tycho-core is built. Cleaning and building all projects is recommended sisu-equinox-launching Unknown Java Problem

but the tycho-core project has no error markers and I have performed a project->clean all

[laeubi]

This also happens for other projects, interestingly from time to time the maven builder kicks in and begin to build something (without any action that would trigger this, e.g I just switching some editor windows). Now the error marker on org.eclipse.tycho:sisu-equinox-api' is gone but remains on other projects. SO it seems there is something stuck or timmed-waiting in m2e

[cpfeiffer]

We recently experienced such a loop as well.
We have configured maven-jar-plugin to generate a MANIFEST.MF with the current timestamp (see the <Build-Time> element).

<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
        <version>${version.maven-jar-plugin}</version>
        <configuration>
                <archive>
                        <manifestEntries>
                                <X-Git-Revision>${X-Git-Revision}</X-Git-Revision>
                                <X-Git-Branch>${X-Git-Branch}</X-Git-Branch>
                                <Maven-Version>${project.version}</Maven-Version>
                                <Deployment-Version>${Deployment-Version}</Deployment-Version>
                                <Maven-Artifact>${project.groupId}:${project.artifactId}</Maven-Artifact>
                                <Build-Time>${maven.build.timestamp}</Build-Time>
                                <Implementation-Version>${project.version}</Implementation-Version>
                                <Implementation-Vendor>${project.organization.name}</Implementation-Vendor>
                        </manifestEntries>
                </archive>
        </configuration>
</plugin>

In eclipse, we have the https://github.com/tesla/m2eclipse-mavenarchiver connector installed, that takes care of generating the manifest in eclipse.

So when a project changes, we get the following chain:

org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.mavenProjectChanged
-> org.eclipse.m2e.core.internal.lifecyclemapping.LifecycleMappingFactory.isLifecycleMappingChanged
  -> org.eclipse.m2e.core.project.configurator.AbstractCustomizableLifecycleMapping.hasLifecycleMappingChanged
    -> org.eclipse.m2e.core.project.configurator.AbstractProjectConfigurator.hasConfigurationChanged

The last method hasConfigurationChanged() compares the previous configuration with the current configuration, which include the concrete timestamps for the manifest. The timestamp's precision is 1s.

So whenver the file gets generated (which triggers a change event leading to the above chain) and the processing takes more than one second (or occurs around the switch to the next second), hasConfigurationChanged() returns true and triggers another build. Ad finitum.

The fix for us is to add a profile with a maven-archiver configuration that uses a hardcoded, stable timestamp instead of the actual time. We activate this profile only inside m2e.

<configuration>
    <archive>
        <manifestEntries>
            <Build-Time>20210101235959</Build-Time>
        </manifestEntries>
    </archive>
</configuration>

[mickaelistria]

Thanks Carsten. Do you think you could provide a minimal reproducer? Also do you see an opportunity for improvement here in m2e (for example keeping finer grain timestamps in memory and compary per nano or milliseconds instead of seconds to avoid loops, or just replacing some <= by < )?

[cpfeiffer]

I can try to create a reproducer. However I'm not sure how m2e could avoid such a situation. I was mostly trying to document the problem so that others can check their setup for a similuar situation.

A greater precision (e.g. ns or ms) would make the problem even worse since the Build-Time in the manifest would change even more quickly and thus the project would be built more often.

A lower precision (e.g. min) would help a bit, but still would lead to unneeded builds. IMHO, the Manifest should never change in eclipse, as long as the code/metadata for it doesn't change. Because every change triggers a build.

I actually need to check the X-Git-xxx properties whether they cause unnecessary builds after doing a commit.

[kiicia]

is there any progress on the issue? it started suddenly after last "big" eclipse update IIRC and it's basically almost impossible to stop manually...

[kjsmita6]

This is happening with us after we updated our Eclipse RCP product to Eclipse 4.21. Restarting the IDE seems to help, but is a major inconvenience and makes the software unusable unless this is done.

[mickaelistria]

Please provide some minimal reproducer (eg minimal project set and steps to reproduce) if you want to see the chances of this being fix increased.

[rotty3000]

Hey All, this was troubling me deeply and we had a bug open for this on osgi/osgi-test and we thought it was in our side (perhaps in bndtools).

However, I finally tracked it down to a loop between org.eclipse.core.internal.events.AutoBuildJob job and org.eclipse.m2e.jdt.internal.DownloadSourcesJob:

• the download job runs and finds source artifacts which appear to be out of date so are queued to be downloaded (because their timestamp is older than the main artifact) however the maven resolver (which is asked to download the artifact) thought differently and decided it didn't need to download it. But nevertheless, the download job thinks there are new files and so asks the classpathcontainer to update which triggers the build job
• immediately, while the download job has yet to totally finish, the build job runs (due to the updated classpathcontainer) but gets cancelled because autoBuildJob.isInterrupted() returns true since it detects the conflicting download job and is cancelled.

The problem is the issue with the two different checks for the source artifact: one by m2e code, and the other by maven.resolver that have different ideas about what is out of date which means the download queue is always refilled with the same files over and over and so it just loops.

HOWEVER, I was able to trigger the issue at will by changing the timestamp directly on the file system of the source artifacts for any dependency referenced by the build.

So, if you really want to eliminate the problem without searching every individual timestamp in your .m2 that might be out of order like so:

osgi]$ ll --time-style=full-iso org.osgi.test.junit4/1.0.1/
-rw-rw-r--  1 rotty rotty 16341 2021-08-05 10:34:56.000000000 -0400 org.osgi.test.junit4-1.0.1.jar
-rw-rw-r--  1 rotty rotty  8078 2021-08-05 10:34:42.000000000 -0400 org.osgi.test.junit4-1.0.1-sources.jar

run something like: find ~/.m2/repository -type f -name "*-sources.jar" -exec touch {} +

this will just update the source artifacts to be newer than the main artifacts and then you should be fine.

[HannesWell]

Thanks for your analysis!
It sounds like it is connected to #252, but just from your description I'm not certain if the solution for #252 is sufficient. Just to make sure, do you use the latest m2e release version 1.18.2 and does your method to reproduce the issue with that version as well?

[rotty3000]

I have only checked 1.18.1.20210618-2246 and as you mention had noted that the logic around this had changed. So I will update and retest as soon as I get a chance.

[kjsmita6]

I am occasionally having this issue using m2e 1.20.1.20220227-1319 on Eclipse 4.23 but the problem seems to be much better (i.e. doesn't block the entire IDE). When it happens, my progress view still shows alternating jobs between "Building" and "Downloading Sources/Javadoc". But like I said, it is not a huge problem as it was before.

Screen.Recording.2022-04-13.at.4.07.07.PM.mov

(goes on forever)

This screen recording is from my Eclipse 4.23 while running our RCP application (from an Eclipse launch config). This does not happen in the RCP application itself.

From previous comments, is it a problem with m2e/pde? Our RCP app does not have m2e/pde (or any PDE for that matter) but my Eclipse 4.23 does.

[laeubi]

With the latest version I see the following being stuck and running over and over again with different projects but never making any progress:

Maybe this gives a hint about what is being the root cause: #619 (comment)

[guw]

So this looks like some kind of event flooding. Is the builder triggering async resource changes, which are propagated outside of the builder?

[laeubi]

I'm now having a workspace where the problem occurs and I can debug it from what I see the problem is that there is one parent project that has errors, thus it don't make it into the ProjectRegistry and then if another project tries to fetch that project is is noticed that it is out of date and needs updates, then it is noticed that the project itself has changed and needs an update and so on....

Thread [Worker-12: Building] (Suspended)	
	ProjectRegistryManager.lambda$3(MutableProjectRegistry, DependencyResolutionContext, Map, Map, IFile, MavenProjectFacade, IMavenExecutionContext, IProgressMonitor) line: 517	
	965013639.call(IMavenExecutionContext, IProgressMonitor) line: not available	
	MavenExecutionContext.executeBare(MavenProject, ICallable<V>, IProgressMonitor) line: 182	
	MavenExecutionContext.execute(MavenProject, ICallable<V>, IProgressMonitor) line: 156	
	ProjectRegistryManager.refresh(MutableProjectRegistry, DependencyResolutionContext, IProgressMonitor) line: 514	
	ProjectRegistryManager.refresh(MutableProjectRegistry, Collection<IFile>, IProgressMonitor) line: 366	
	ProjectRegistryManager.refresh(Collection<IFile>, IProgressMonitor) line: 320	
	MavenBuilder$1(MavenBuilder$BuildMethod<T>).getProjectFacade(IProject, IProgressMonitor) line: 150	
	MavenBuilder$1(MavenBuilder$BuildMethod<T>).lambda$0(int, Map, IProject, IMavenExecutionContext, IProgressMonitor) line: 88	
	1466893426.call(IMavenExecutionContext, IProgressMonitor) line: not available	
	MavenExecutionContext.executeBare(MavenProject, ICallable<V>, IProgressMonitor) line: 182	
	MavenExecutionContext.execute(MavenProject, ICallable<V>, IProgressMonitor) line: 156	
	MavenExecutionContext.execute(ICallable<V>, IProgressMonitor) line: 103	
	MavenBuilder$1(MavenBuilder$BuildMethod<T>).execute(int, Map<String,String>, IProgressMonitor) line: 87	
	MavenBuilder.build(int, Map<String,String>, IProgressMonitor) line: 197	
	BuildManager$2.run() line: 1024	
	SafeRunner.run(ISafeRunnable) line: 45	
	BuildManager.basicBuild(int, IncrementalProjectBuilder, Map<String,String>, MultiStatus, IProgressMonitor) line: 254	
	BuildManager.basicBuild(IBuildConfiguration, int, IBuildContext, ICommand[], MultiStatus, IProgressMonitor) line: 311	
	BuildManager$1.run() line: 400	
	SafeRunner.run(ISafeRunnable) line: 45	
	BuildManager.basicBuild(IBuildConfiguration, int, IBuildContext, MultiStatus, IProgressMonitor) line: 403	
	BuildManager.basicBuildLoop(IBuildConfiguration[], IBuildConfiguration[], int, MultiStatus, IProgressMonitor, int, boolean) line: 514	
	BuildManager.basicBuildLoop(IBuildConfiguration[], IBuildConfiguration[], int, MultiStatus, IProgressMonitor) line: 462	
	BuildManager.build(IBuildConfiguration[], IBuildConfiguration[], int, IProgressMonitor) line: 544	
	AutoBuildJob.doBuild(IProgressMonitor) line: 161	
	AutoBuildJob.run(IProgressMonitor) line: 255	
	Worker.run() line: 63	

[laeubi]

In refreshPhase2 there is:

 for(Capability capability : changedCapabilities) {
      context.forcePomFiles(versionedCapabilitiesOnly ? newState.getVersionedDependents(capability, true)
          : newState.getDependents(capability, true));
    }

this adds "dependents" pom files to the context, which leads to that the queue never gets empty here... (from what I can see).

[laeubi]

I have a fix for this, just need to think if we maybe can do better than my first simple approach ...

[laeubi]

I can confirm, after getting the stuck again with an older m2e release, that with the new code now it is correctly detected and the cycle is left after one initial improvement of the build cycle.

[HannesWell]

I can confirm, after getting the stuck again with an older m2e release, that with the new code now it is correctly detected and the cycle is left after one initial improvement of the build cycle.

That's great news and a good reason to go for M2E 2.0 :)
Thanks for your work.

[ahoehma]

Hi guys ... happy new year to all.

I just found this issue here ... my eclipse shows similar symptoms.
Have 2 projects open in workspace. Both have many maven plugins configured, jaxb, aspectj etc.
After "update projects" (without clean) ... the progress hangs forever in "Resolve plugin dependency".
But no more details, no m2e console log, nothing in "Maven Workspace Build".
How can I get more logging for m2e processing?

Is it worth to create an issue for that? Would be hard to provide a project to reproduce that because of closed source :(

I'm using latest snapshot version of m2e.

I was able to stack the hanging process:
m2e-hangs.txt

"main" #1 prio=6 os_prio=0 cpu=276984.38ms elapsed=4705.08s tid=0x0000029d6a295f00 nid=0x1d68 in Object.wait() [0x0000009e20cfa000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait([email protected]/Native Method) - waiting on <no object reference available> at org.eclipse.core.internal.jobs.ThreadJob.waitForRun(ThreadJob.java:324) - locked <0x000000067d400020> (a java.lang.Object) at org.eclipse.core.internal.jobs.ThreadJob.joinRun(ThreadJob.java:208) at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:95) at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:316) at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:124) at org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:2330) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2375) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2405) at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:131) - locked <0x000000069c28ab28> (a org.eclipse.ui.actions.WorkspaceModifyDelegatingOperation) at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run(WorkspaceOperationRunner.java:76) at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run(WorkspaceOperationRunner.java:66) at org.eclipse.ui.editors.text.TextFileDocumentProvider.executeOperation(TextFileDocumentProvider.java:461) at org.eclipse.ui.editors.text.TextFileDocumentProvider.synchronize(TextFileDocumentProvider.java:1121) at org.eclipse.m2e.editor.pom.MavenPomEditor.initializeSourceDocument(MavenPomEditor.java:399) at org.eclipse.m2e.editor.pom.MavenPomEditor.addFallbackEditors(MavenPomEditor.java:363) at org.eclipse.m2e.editor.pom.MavenPomEditor.addPages(MavenPomEditor.java:336) at org.eclipse.ui.forms.editor.FormEditor.createPages(FormEditor.java:143) at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:333) at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.createPartControl(CompatibilityPart.java:158) at org.eclipse.ui.internal.e4.compatibility.CompatibilityEditor.createPartControl(CompatibilityEditor.java:96) at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:365) at jdk.internal.reflect.GeneratedMethodAccessor282.invoke(Unknown Source) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke([email protected]/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke([email protected]/Method.java:568) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:58) at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:995) at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:960) at org.eclipse.e4.core.internal.di.InjectorImpl.internalInject(InjectorImpl.java:140) at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:403) at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:330) at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:202) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:91) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:60) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:42) at org.eclipse.e4.ui.workbench.renderers.swt.ContributedPartRenderer.createWidget(ContributedPartRenderer.java:132) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:995) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:659) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:763) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:728) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:712) at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.lambda$0(PartServiceImpl.java:105) at org.eclipse.e4.ui.internal.workbench.PartServiceImpl$$Lambda$384/0x0000000801268a58.handleEvent(Unknown Source) at org.eclipse.e4.ui.services.internal.events.UIEventHandler.lambda$0(UIEventHandler.java:38) at org.eclipse.e4.ui.services.internal.events.UIEventHandler$$Lambda$321/0x00000008010ff460.run(Unknown Source) at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:183) at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:133) at org.eclipse.swt.widgets.Display.syncExec(Display.java:4785) at org.eclipse.e4.ui.workbench.swt.DisplayUISynchronize.syncExec(DisplayUISynchronize.java:34) at org.eclipse.e4.ui.services.internal.events.UIEventHandler.handleEvent(UIEventHandler.java:38) at org.eclipse.equinox.internal.event.EventHandlerWrapper.handleEvent(EventHandlerWrapper.java:205) at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:203) at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:1) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234) at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:151) at org.eclipse.equinox.internal.event.EventAdminImpl.dispatchEvent(EventAdminImpl.java:133) at org.eclipse.equinox.internal.event.EventAdminImpl.sendEvent(EventAdminImpl.java:75) at org.eclipse.equinox.internal.event.EventComponent.sendEvent(EventComponent.java:44) at org.eclipse.e4.ui.services.internal.events.EventBroker.send(EventBroker.java:55) at org.eclipse.e4.ui.internal.workbench.UIEventPublisher.notifyChanged(UIEventPublisher.java:63) at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:424) at org.eclipse.e4.ui.model.application.ui.impl.ElementContainerImpl.setSelectedElementGen(ElementContainerImpl.java:170) at org.eclipse.e4.ui.model.application.ui.impl.ElementContainerImpl.setSelectedElement(ElementContainerImpl.java:188) at org.eclipse.e4.ui.internal.workbench.ModelServiceImpl.showElementInWindow(ModelServiceImpl.java:660) at org.eclipse.e4.ui.internal.workbench.ModelServiceImpl.bringToTop(ModelServiceImpl.java:624) at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.delegateBringToTop(PartServiceImpl.java:790) at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.bringToTop(PartServiceImpl.java:401) at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.showPart(PartServiceImpl.java:1264) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:3210) at org.eclipse.ui.internal.WorkbenchPage.lambda$9(WorkbenchPage.java:3100) at org.eclipse.ui.internal.WorkbenchPage$$Lambda$2971/0x0000000802795910.run(Unknown Source) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:74) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:3098) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:3068) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:3059) at org.eclipse.ui.ide.IDE.openEditor(IDE.java:548) at org.eclipse.ui.ide.IDE.openEditor(IDE.java:508) at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:367) at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:172) at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:288) at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:254) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:274) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:252) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerActionGroup.handleOpen(PackageExplorerActionGroup.java:366) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart$3.open(PackageExplorerPart.java:545) at org.eclipse.ui.OpenAndLinkWithEditorHelper$InternalListener.open(OpenAndLinkWithEditorHelper.java:48) at org.eclipse.jface.viewers.StructuredViewer$2.run(StructuredViewer.java:800) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) at org.eclipse.ui.internal.JFaceUtil$$Lambda$134/0x0000000800db8c40.run(Unknown Source) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:174) at org.eclipse.jface.viewers.StructuredViewer.fireOpen(StructuredViewer.java:797) at org.eclipse.jface.viewers.StructuredViewer.handleOpen(StructuredViewer.java:1116) at org.eclipse.jface.viewers.StructuredViewer$$Lambda$576/0x000000080135f908.handleOpen(Unknown Source) at org.eclipse.jface.util.OpenStrategy.fireOpenEvent(OpenStrategy.java:296) at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:331) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4256) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1066) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4054) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3642) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1155) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1046) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155) at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:643) at org.eclipse.ui.internal.Workbench$$Lambda$237/0x0000000800f09730.run(Unknown Source) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:550) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:171) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:152) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:136) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:402) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0([email protected]/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke([email protected]/NativeMethodAccessorImpl.java:77) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke([email protected]/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke([email protected]/Method.java:568) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:659) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:596) at org.eclipse.equinox.launcher.Main.run(Main.java:1467)

PS: even "Cancel" the Updating doesn't do anything ... just (Cancel Requested) :(

[laeubi]

Is it worth to create an issue for that? Would be hard to provide a project to reproduce that because of closed source :(

Without any reproducing test-case the only thing you can setup a dev environment and debug it yourself. Alternatively you can contact me to enter a contract for analyze / fix it for you and I can sign a NDA or similar.

[ahoehma]

@laeubi is it possible to enable more logging etc ... and how? please give me a hint. I would like to see something like "resolving foobar for plugin blubs" ... somewhere is a endless loop or something.

[laeubi]

You can open the "Maven Console" to get the maven log but I doubt this will give you more insights of the problem.

[reckart]

I often have a similar problem that it hangs at resolving plugins when importing a new existing maven project into the workspace. After a couple of tries of killing Eclipse and retrying, it usually works. Also, what seems to help me is to disable auto-build before importing the project. IMHO it is very different from the endless build loop that is described in this bug (and which I also had experienced at various points in the past).

[ahoehma]

@reckart my current scenario is more about hanging after trigger an update for already imported projects. I have a little feeling that its maybe something deep inside the artifact-resolving specially for "invalid" artifacts, timeouts while talking with nexus etc. Not sure if this is already in the code... but it would be good to have some properties to pimp timeouts etc. to force "hard crashes" here and there to see more clearly where the real cause is. Endless loops and killing eclipse is really ugly. But I imagine its really complex stuff inside m2e :)

[reckart]

I didn't try it yet, but if you can consistently reproduce the issue, you might try firing up VisualVM and use the CPU sampler to check in which part of the code the hang occurs.

[u023871]

This bug seems to have returned in 2022-12. In 2022-09 it was fine!

[laeubi]

This bug seems to have returned in 2022-12. In 2022-09 it was fine!

Reproducerin test-case?

[u023871]

Wow you are fast. Test case is hard to describe... Only wanted to check whether this is a known issue.

Maven console is going wild after

• right click project
• Maven
• Update project...

and the process never stops.

The project has 33 modules.

The info in lower right corner all the time tells you "Updating Maven Project: (XY%)", with percentage changing.

You can also see that memory consumption is very high (up to 4G at the moment, will monitor whether it comes to an OOME), but also frequently changing.

Maven console is writing tons of lines... and does not stop.

[u023871]

Ok the more I read the original posted comments and links, the more I seem to have a different issue.

I can indeed stop the build process and do not need to kill the Eclipse process.

But of couse this does not help me, as my project is not built anymore...

Will try deleting and importing cleanly... maybe there was an issue converting the old project config files to the new version...

BTW here the build info:
_Eclipse IDE for Enterprise Java and Web Developers (includes Incubating components)

Version: 2022-12 (4.26.0)
Build id: 20221201-1913

(c) Copyright Eclipse contributors and others 2000, 2022. All rights reserved. Eclipse and the Eclipse logo are trademarks of the Eclipse Foundation, Inc., https://www.eclipse.org/. The Eclipse logo cannot be altered without Eclipses permission. Eclipse logos are provided for use under the Eclipse logo and trademark guidelines, https://www.eclipse.org/logotm/. Oracle and Java are trademarks or registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

This product includes software developed by other open source projects including the Apache Software Foundation, https://www.apache.org/.

Lombok v1.18.26 "Envious Ferret" is installed. https://projectlombok.org/_

[u023871]

@laeubi Ok meanwhile my MacBook crashed, got obviously too hot with 2 Eclipse instance endlessly trying to build (tried 2 different project versions in order to exclude issues with our own code - but at least 1 of them was completely developed on the old 2022-09). Additionally I noticed some increased memory consumption, which rose up until 5.5G before I stopped it. Also I missed that indeed the Eclipse instances do not exit on closing them, in case a Maven build is running and although I pressed the red square button, and indeed need to be killed. However, I have a suspicion... Upgraded lombok agent a few days ago, will downgrade again and retest - although I already worked with that setup for a few days, very weird...

Oh MacOS even created a nice crash report...

Rolled back to 2022-09 from a Time Machine backup and the issue is gone. Will wait for 2023-03 and retry...

[u023871]

Hi!

After I still had the same issues with our project with updates from 2022-09 to or even fresh installations of Eclipse 2024-03 with m2e core 2.6.0, I stumbled over these m2e release notes, allowing to disable automatic builds for single projects:

https://github.com/eclipse-m2e/m2e-core/blob/master/RELEASE_NOTES.md#project-preference-for-automated-maven-project-configuration-updates

Project preference for automated Maven project configuration updates
Automatic configuration updates for Maven projects can now be disabled the in the project preferences. This allows to disable these updates individually per project and to store the setting in a preference-file under version control, which is useful for projects that require special workspace configuration that doesn't exactly match the configuration in the pom.xml.

However, this option is also available as global Maven settings in Eclipse preferences.

After disabling it globally, the endless loop Maven build issue is gone :-)

Most probably I will have to manually update the Maven project in Eclipse now after pom.xml changes, but at least we can upgrade our project to Java 21 now (which was not supported by 2022-09).

Just wanted to share...