Increase the VM memory. Build maven first and then open eclipse can also help. The build takes a huge amount of memory and consumer Linux has no sane defaults to protect you from running out of memory (I recommend rlimit and cgroups process limits).
Hmmm, I will give it a try, but never ran into issues giving the Ubuntu VM 2 Cores and 4096MB of memory.
Thanks David.
Sorry - I wasn’t talking about the default - just on the statement about “never”. Don’t care about the default - just wanted you to be aware there are people who do want to compile the whole thing and find value in doing it.
Scaling shouldn’t really be an issue - even with a 1000 addons, the system is still pretty darn small to what is commonly dealt with (I’m talking build time btw - not testing time which is a totally different matter). If the build becomes that long - either there is an issue with the build system itself or it’s being run on unpowered hardware - but that’s all beyond the issue. If you have the hardware and the want to build the all the addons, there should be that option (again, probably not by default)
That’s the misunderstanding then. I’m talking about the default.
There seems to be an issue under Linux. Following the instructions, I was able to get my Eclipse IDE up and running under Windows …
As you may have noticed, I’ve created a few PRs to workaround the (what it looks like) bnd issue (bndtools/bnd#3220):
It fixes the endless builds for me and I hope they are reviewed/merged soon!
To fix the endless build (once they are merged), make sure you update/rebase your repos/branches to include these changes or close projects from the repos you don’t use. Then make sure the reactor (root) project of these repos are build, either by rebuilding everything ( mvn clean install ) or a quick non-recursive build at the repo root ( mvn clean install -N ).
Usually Eclipse will pick up these changes and prompt you to update the Maven project configuration. If it does not you can right click on a project and force it to update the projects:
Then Select All projects and click OK.
It will still take a while to build everything, but at least it should finish building! 
I launched the demo app to debug some bindings (Harmony Hub, LIFX, Nest, Plugwise) last week and it worked for me. For the Harmony Hub Binding to work I had to manually add its dependency to the index as workaround (see earlier post). We do need a proper fix for that so it works out of the box.
It works for me on Ubuntu 18.04.2. But I do always give my Eclipse 4GB of memory instead of 2GB in eclipse.ini (-Xmx4096m) since I have plenty of RAM.
1 Like
I gave it 3GB yesterday 
Thanks, let’s hope it goes quickly together so I can run tests.
Hi @wborn ,
I saw a fused PR (5660), other 2 PR not (75-842)
Do I have to wait for two more PR to run tests with Eclipse IDE?
It should also work when you close all core/webui projects in your workspace until those PRs are merged. You can also apply the same changes of my PRs to your repo checkouts. It’s only a few lines. 
OK thanks,
I install only Java Development and Add-on in Eclipse.
So if I only apply your changes to Add-on should it work?
Yes that should work! Just make sure you build the root project and then update the Maven projects like I described in my earlier post.
I’m able to compile and run plugins that don’t have any external dependencies like the astro binding. However, when I try to build e.g. the airvisualnode binding (the first I found with an external dep) I get the following errors after “Resolve”:
Resolution failed. Capabilities satisfying the following requirements could not be found:
[<>]
⇒ osgi.identity: (osgi.identity=org.openhab.binding.airvisualnode)
⇒ [org.openhab.binding.airvisualnode version=2.5.0.201906010944]
⇒ osgi.wiring.package: (&(osgi.wiring.package=jcifs.netbios))
I then followed the post from @wborn and added the following dependency (copied from the airvisualnode pom.xml) to the openhab2-addons\bom\runtime-index\pom.xml:
<dependency> <groupId>org.samba.jcifs</groupId> <artifactId>jcifs</artifactId> <version>1.3.17</version> </dependency>
After that, I run again mvn -DskipChecks -DskipTests clean install on the openhab2-addons folder, but the error message stays the same.
What did I miss?
I retested it and got that binding working by adding that dependency instead to bom/openhab-addons/pom.xml . Then run mvn clean install on that BOM project and using the “Resolve” button should work. So I must have mistaken that BOM for another one just before I finished my day. 
I hope that works, then I’ll update my previous post!
Yes, that worked, Thanks a lot!
1 Like
@wborn Is the infinity build now be resolved by the changes applied two days before?
About the missing 3rd party libs used by addons:
- Are all 3rd party libs already OSGi ones?
- Are all 3rd party libs already present in the openHAB or another Maven repository?
If the chosen scope of the 3rd party libraries is compile they should be present at compile and runtime and so will be present in the created index used by the Bnd resolver.
If you would like to ensure that different addons are using the same coordinates for compile and runtime dependencies you could use a compile BOM and a runtime BOM for the addons itself.
@David_Graeff I don’t want to step into the discussion if the BOM can be avoided and if it would make more sense to version every addon separately etc. I assume I share some of your ideas but I don’t think it is helpful for anyone if we mix all different topics here.
All PRs have been merged now. So the infinite build loop should be resolved when you update your repository clones to the latest master, build the reactor POMs and update the Maven projects in your Eclipse workspace.
The plan is that all dependencies will be available in Maven repositories as OSGi bundles. @J-N-K is creating proper bundles from JARs in this bnd branch, see also PR #5503.
Changing the scope of the add-on dependencies from provided to compile indeed also fixes the resolution issue. It’s probably the easiest way to manage these because it doesn’t result in a lot of duplication. Do you know if it might cause any further issues?
Just to note that I never run into the problem.
So my question has been more about “should it be solved” or “is it solved”.
But I assume your comment should be read as: “If you follow that … instructions, it will be solved”.
If e.g. an Apache Commons library will be used in different versions in different addons all of them will be part of the index. So it can increase the time the resolver needs to resolve the demo application.
Using the compile scope will also eliminate the differentiation between API and implementation as you use at runtime (potentially) what you compile against. So, it will not work reliable for pure API dependencies. But also for them it would be possible (in general) to add one dependency using scope provided (API) and another one using scope runtime (implementation). Bnd will handle that correctly. I don’t know if the Eclipse m2e mechanism can differ correctly between all that scopes.
I started with a clean Eclipse IDE, installing 03-2019 (Java development + OH2 Add-on) . The problem is solved.
Thanks to all the maintainers.
What is unclear to me is all the problems detected by the Resolve window.
Another not very clear thing is the inclusion of a new binding, at the time I solved with:
mvn -DskipChecks -DskipTests clean install -U
Within Esclipse IDE I failed.
The workaround resolves the endless build for @gozilla01 and me.
I’ll then do some testing to see if there are any major issues when the dependency scope of all the add-on dependencies is changed to compile. Currently it cannot resolve any add-on dependencies. IIRC with PDE it also had a habit of adding too many dependencies. 
I don’t see any in the screenshot?
Without seeing actual errors/warnings/stacktraces I’m afraid nobody can help you with that.