Hm. Did you select “openhab2-addons development” in the install dialog? Don’t do that.
Not all bindings will work with this setup, especially the voice addons will not (they require native libraries at that does not work).
The guide will also change in the future once more to be in line with the vscode one (eg starting a real openhab instance in debug and remote debug on it).
Oh. But at least the feature installer of karaf was linked I guess. Because you could install additional extensions from within the debug sessions Paper UI.
Because everything will be build. That does not only take hours, but we also still have addons that don’t work on every operating system (some TS services for example). You should really only build the one or two bundle that you are interested in.
I once suggested multiple repositories. You do not want that. That’s fine. But don’t force everyone to download half the internet and wait two hours before the intented one-line fix can be applied.
What is the selling point of OH in contrast to for example HomeAssistant? (Atm they have the better UI, the easier development flow, and resulting of that the bigger community and they gain support for new tech faster).
If you just put the focus on development, I think it is that we can live debug on a running OH instance. That’s the one thing that the Python and NodeJS guys can do so easily.
The VScode developer workflow (see Introduction | openHAB) is already using a running OH/Karaf instance. And IMO that’s what we should do for all other supported IDEs as well and ditch the demo. It just works so different to Karaf and people here always asking why they have runtime dependency problems when they press Debug although their features.xml file contains this and that.
We don’t have enough man power for two independent runtime systems.
I am the one who wrote the latest (draft) guide for Eclipse IDE, having tried myself many times to set again and again a decent IDE.
After the whole project has been migrated away from PDE, I (like many others) was not able to test any binding anymore.
I feel we are still far from having a stable situation.
I humbly think that before addressing other problems/evolution this problem of not having a stable decent IDE (with Eclipse) is the current emergency, or the project will not progress anymore.
I guess support from all maintainers now should be concentrated towards re-establishing a decent situation.
The first problem is with bndtools triggereing continuous builds (see issue #5554), at least on Windows (but guess is same for other OS).
That probably is a bug in bndtools.
Consequence is that if you select “openhab2-addons development” in the install dialog, the IDE tries to build all addons and this will never end.
It’s not just about waiting hours, it will never end! (at least on Windows)
That is why in the guide I have (temporary) put to checkout openhab2-addons manually from Git and import then compile only the interesting binding.
Here comes the second problem: even if you checkout manually openhab2-addons and then import+compile from Eclipse only the binding you are interested on, this does not guarantee that you will be able to solve all dependencies in the bndtools Resolve button and you will get errors like this:
Resolution failed. Capabilities satisfying the following requirements could not be found:
[<<INITIAL>>]
⇒ osgi.identity: (&(osgi.identity=org.openhab.voice.pollytts)(version>=2.5.0))
⇒ [org.openhab.voice.pollytts version=2.5.0.201905251015]
⇒ osgi.wiring.package: (&(osgi.wiring.package=com.amazonaws.auth))
I do not know the reason for this, but probably it is exaplained here.
The only way to get out of these kind of errors I have found is to:
close Eclipse
go to the main openhab2-addons dir, do a mvn -DskipChecks -DskipTests clean install there (it takes not hours but about 20/30mins according to internet and PC, which is manageable)
and then if you open Eclipse again finally you have your binding, and related dependencies, loaded and you can run OSGi from bndtools
However, as also David is pointing out, re-compiling all bindings from Git is dangerous as it may happen in some point in time where one of the 100+ binding does not compile, or is missing a dependency, and then this second steps fails for some reason you do not understand, also because you are not interested at all in the binding it’s failing.
In conclusion:
have @maintainers a clear idea how to have in the IDE only the compiled versions of the bindings, and just concentrate in the one you want to source/develop/debug ?
How other developers are doing in this current stalled situation that is lasting for weeks now ? Is anyone really using Eclipse after migration to bndtools ?
We only hear mostly from David and miss the opinions/solutions/suggestions from other developers/maintainers as well.
Thanks for any clarification and kind support to unlock this situation!
For my part, I am developing with IntelliJ, and “debugging” by running my system in a docker image and reading log files. Not the fastest turnaround, and proper debugging would be nice, but at least I can move forward with my bindings.
I agree 1000%
Now they are months with this situation, but above all there are no clear and official announcements.
There are many users Openwebnet fed up, they want to go away, to wait for @massi with the formalization and above all with new implementations.
I understand the effort of all the maintainers, thank you all … I love OH. But it is time to prioritize 1 this issue.
Kai you are great … I have a lot of respect for all the time and effort you dedicate to OH.
Allow me to give you a hint, take the problem in hand and please get us out of this nightmare.
I hope that you are wrong here. I would actually think that the current IDE setup IS stable and we just have some minor issues left - one being the build cycle, the other being very few bundles that have some dependency issues (like PollyTTS).
My suggestion here would be to let the IDE do the cloning and import and we merely add a note in the docs that all unnecessary projects can be closed by the user - this should hopefully work smoothly and it is much easier for the user.
When I tested the setup, I was able to get a workspace with ALL projects compiling and showing no errors.
Please note that I was never a friend of switching the build system / IDE… I just gave in to the permanent complaints about Tycho from many developers. I thus also left the process of the migration to others and I am more or less in the same boat trying to get support from the “bnd gurus” on how to get the IDE working as smoothly as before.
So a million thanks to @massi for trying to find a decent way of working and documenting what he found - let us all work together on this and tackle every remaining issue one after the other!
