This seems to be eclipse installer related. I made a copy of my folders (.m2, .p2, openhab-main) from my former computer to the new one and everything seems to run normally.
I am now having the same issue. 
It started on my existing 2022-03 IDE setup, so I tried a fresh 2023-03 IDE install, but it is the same issue there.
@triller-telekom I do not even have added a single add-on, so that does not seem the cause for me.
I also tried rearranging the runbundles order, but no luck.
If anybody has a good hint how to resolve this issue, I’d be very thankful.
Hi, no solution but I like to tell anyway.
I have had an IDE setup as 2022-12 used since a week back, this had have Resolve mode as manual and non Resolve has been done, and everything works as usual.
I then yesterday did an manual Resolve and the result is as below. I did Run OSGi at 23:20, and then went to bed.
This is what I found this morning:
Exception in thread “pool-1-thread-1” java.lang.OutOfMemoryError: Java heap space
at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1663)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1182)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:899)
at java.base/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1070)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1589)
Welcome to Apache Felix Gogo
g! 00:04:38.328 [INFO ] [org.openhab.core.Activator ] - Starting openHAB 4.0.0 (build Unknown Build No.)…
Main Gui works as usual.
Best Regards Basse
Any solution to this ?
Same here, fresh install of Eclipse 2023-03, on an Apple M1 with 32GB RAM. Deadly slow
I see a lot of these Equinox resolver threads. Is that normal ?
It is and it isn’t - resolver is there to compute dependency graph between packages and thus bundles which needs to be started. Not only Equinox Resolver but also Felix Resolver are known for running into troubles under certain conditions. Since package graph is usually fairly large, especially if you run entire openhab, depending on depth of the graph query you might get almost infinite number of permutations. Interestingly enough both resolver implementations avoid running into stack overflow errors. 
If you look for a solution I have two suggestions:
- Try disabling and enabling specific bundles in a hope to find a root cause, note it might be two or more bundles which contribute to problem by making clash or diverge of transient dependencies.
- Plug a debugger into resolver and find where it begins to get into infinite cycle, then look which packages are causing it. Simple solution will be avoiding them, but a permanent solution of this problem will be patch which will solve an algorithmic puzzle in resolver logic.
Cheers,
Łukasz
1 Like
Well, I was more referring to the number and state of these threads. Debugging or even doing this by trial-and-error is finding a needle in a hay stack.
The short-term solution is to move away from Eclipse and go with VS Code which is using the regular distribution with Karaf. Unless some is volunteering to craft an Eclipse setup that allows one to swiftly debug against a separately running JVM
Any update here, I’m now running into the same isse.
Eclipse 2023-03 on macOS with M1, Zulu 17.
Nope - Personally I moved away from Eclipse and I do all dev stuff in VS Code instead
Not really. I now avoid hitting “resolve” myself. The checked in launch config works for me, so I manually add stuff that I need without automatic resolution.
I’m back on track
- platform macOS, M1 chip
- I clear .m2 and .p2 folders
- did a complete fresh install
- when IDE was initialized I did an update dependencies, run debug → ok
- Maven->Update project
- update dependencies, run debug → ok
- then changed the branch
- added manually a jetty dependency and my binding
- update depencies, run → ok
The only thing, which remains (was also before): Every time I save code (and auto build is enabled) I get the following message:
Error executing jar goal: Failed to execute mojo org.apache.maven.plugins:maven-jar-plugin:3.0.2:jar {execution: default-jar}
Failed to execute mojo org.apache.maven.plugins:maven-jar-plugin:3.0.2:jar {execution: default-jar}
You have to use a classifier to attach supplemental artifacts to the project instead of replacing them.
Exact same thing here, I get that error when building and over a thousand build errors.
I suspect something is just wrong in the OH build configs, assuming I have some specific version of something I don’t have.