[Solved] Problem install Eclipse IDE

I performed further tests.
I started with a clean IDE and installed last 2019-03 and selected OpenHAB Development.
image

image

Without touching anything there are no bindings or voices
image

Press Resolve


Press Select All + Update and Resolve

Press Cancel
Many bindings and entries are inserted in the window
image
image
The problem is in the demo or Distro
@David_Graeff @wborn @Kai
How can it be solved?

The issue is that the dependencies of add-ons are missing from the BOM used to resolve them.
As a temporary workaround you could add the dependencies of the add-on to bom/openhab-addons/pom.xml:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>org.openhab.addons.bom</groupId>
    <artifactId>org.openhab.addons.reactor.bom</artifactId>
    <version>2.5.0-SNAPSHOT</version>
  </parent>

  <artifactId>org.openhab.addons.bom.openhab-addons</artifactId>
  <packaging>pom</packaging>

  <name>openHAB Add-ons :: BOM :: openHAB Add-ons</name>

  <dependencies>
    <!-- The add-on dependencies using the default (compile) scope -->
    <dependency>
      <groupId>com.github.digitaldan</groupId>
      <artifactId>harmony-client</artifactId>
      <version>1.1.4</version>
    </dependency>
    <!-- Followed by all other existing content -->

Then if you build bom/openhab-addons with mvn clean install bndtools should have no issues if you press the Resolve button.

This will only work for dependencies that are OSGi bundles. So it won’t work for add-ons using wrapped JARs like Polly TTS. There’s a draft PR for creating bundles of 3rd party libraries

What would be the best way to resolve these issues properly @maggu2810?

@J-N-K
Hello,
how did you install IDE?
I can not!!!

We should use karaf instead of the demo app for development to properly solve this. Like it was done in the pde days.

Karaf wasn’t used when launching openHAB from Eclipse in the PDE days. :wink:

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.

Why not? That’s the whole point of this option…

Just ftr, that’s intentional.

That sounds scary. You should only add what you need as mentioned in step 10.

We should use karaf instead of the demo app

No, we should get the demo app working, just as we had it before with PDE…

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 openhab.org/docs) 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.

Thanks a lot @kai for jumping in the discussion…

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:

  1. 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 ?
  2. 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’m using Eclipse,deploy my bundle to an OH installation running in debung mode and use the remote debugger.

I installed 2.5 latest build on both raspberry and local win10
Remote debugging how do you configure it?

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.

Right-click on the pom.xml, “Debug As”->“Debug Configurations”->“Remote Java Application”, Add a project name, host-address and port=5005. Done.

Thank you very much for the practical feedback, I will do some tests. I hope to succeed … Eventually I will disturb you again !!!
Thanks again.

I absolutely agree with you and I made the same comment here a few weeks back.

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!

This definitely also needs to be added to the documentation. It is so simple, but SOOO helpful, especially for debugging a production system.

3 Likes

I suspect that was referring to the way the “recommended way” keeps changing every few days. It is annoying when you follow the setup documentation very carefully and then 2 days later the documentation now recommends a different way and there is no announcement on what has changed or that you now need to check for updated information.

I find it to be stable as in no crashes but…

  1. Too complex to get a new binding setup and running in the new run app. Will have to check out the above suggestion of right hand click on pom.
  2. Sick of having to do a clean and build all before I can see any errors show up in the IDE. I have to disable the auto build as it gets stuck in a loop forever as the setup instructions mention.
  3. Handling dependancies is too complex and don’t get packaged into a single JAR.

The selling points are:

  1. More stable than HA
  2. Less breaking changes as they are working flat out to catch up with what we have and to improve past what Openhab has.
  3. Far better Zwave support, well done devs.
  4. Free use of myopenhab/cloud.

But the goal posts are always moving and in a years time I would expect 2 of those things will be fixed with HA. 25,000 forks of the Home Assistant code seem to suggest they have far more developers then Openhab, and add to this they have landed in the top 10 fastest growing Opensource github projects.

I really hate seeing Openhab appearing to stand still. I know everyone is doing great work and thank you heaps for it, I just wish there were updates to show we are moving forward towards a goal and how close we are getting to reaching it.

@David_Graeff
How is the new gen User Interface coming along? I have been hanging out to see it released.

1 Like

Not so much anymore. The reason that it appeared stable was that nothing was touched for a long time. And now all the technical debts accumulated. And fixing them one after the after with the little time every one has leads to a very unstable OH.

But it had to be done. We are no Java 11+ compatible. We were stuck with Java 8 before. We now use an industry acknowledged way of building bundles instead of the Eclipse specific one from before. We now support multiple IDEs whereas we couldn’t before.

They have a “just do it” mentality. While openhab is more in the discussion area. Of course as a consumer, upgrades in HA may destroy your working setup. With HA you do not want to upgrade often. On the other hand you have fresh tech support way earlier. OH need to change here,

  • introduce semantic versioning for components and addons, for example, so that development can happen in parallel,
  • stop to download half the internet if you should want to quickly fix a one-liner in one bundle.

Which scales badly. If you study the source code you know why. Mozilla also has a free remote access offer for their Webthings framework. And they established it way cheaper, with smart cloud function use, geo aware and more robust (Rust written backend). I think myopenhab should cost actually to fund development. HA does it right.

Python or JavaScript projects also don’t bundle everything in one packet. We can’t do that as well. Because of transitive dependencies you will end up with hundreds megabyte jar files.

The problem is that we use a system (OSGi) that is not really compatible to the old java infrastructure ie maven repositories. OSGi actually requires different repositories (orb) to be easily usable. But then we hit the problem that every other project uses maven repos. You see it’s not easy to find a simple setup because we are working against the current.

The UI part is finished and I started to work on Core. But openHABs REST interface is absolutely broken atm. It causes high CPU usage, is based on a 7 year old unmaintained library and is absolutely inconsistent … did I mention broken already?! See https://github.com/openhab/openhab-webui/issues/24#issuecomment-493075190 for more information.

I tried to fix the old-dependency problem in Core (see https://github.com/openhab/openhab-core/pull/739), but the old sitemaps concept that I needed to touch as well, blocks me from finishing my work. It’s such a broken code, it should really be removed ASAP IMO. For me OH is not usable right now. Friends of mine told me that OH 2.4 work unreliable for them and when we plan to release 2.5. And the only recommendation that I could give was: Try HomeAssistant or IoBroker. It’s really sad atm. And if you follow the developer section, I really tried to reform OH to have a future.

It does not seem so stable for OH use-case:

  • the recursive building is a major problem IMHO (and no answer from the bndtools developer yet). Is OH the only one project in the industry affected by this issue?
  • dependency resolution from bndtools does not work either. Since I am not bndtools/OSGi expert at all I do not understand if this is a limitation of bndtools or a problem with the current projects setup in the OH buildsystem