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…
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.
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.
Handling dependancies is too complex and don’t get packaged into a single JAR.
The selling points are:
More stable than HA
Less breaking changes as they are working flat out to catch up with what we have and to improve past what Openhab has.
Far better Zwave support, well done devs.
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.
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.
I tried to fix the old-dependency problem in Core (see [WIP] Use OSGi Compendium R7 JAX-RS Whiteboard pattern for REST by davidgraeff · Pull Request #739 · openhab/openhab-core · GitHub), 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.
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
Yes I guess so. A professional Java developer does not use Eclipse but Intellij. Google switched from Eclipse to Intellij for their Android development (rebranded as Android Studio).
Let’s crunch some numbers in a very un-scientific way.
Due to Java Spring, modular Java 9 and other successful projects that do not use OSGi anymore people / projects that actually use OSGi is probably about 5%.
Let’s get a final number here: 14%*5%*28% = 0.19% of all developers use Java with OSGi on Eclipse.
But again that is the most un-scientific way of getting an number here, but you probably got what I’m trying to say here: There are not many projects with the programming language (Java), programming model (OSGi) and IDE setup (Eclipse) that we use.
OSGi
Eclipse itself is OSGi. They use it in the way how OH did it before (PDE). That’s why it worked so “well” in Eclipse before (But in no other IDE) and has many Dialogs and UI support. Bnd is just a “plugin” for Eclipse. And the Bnd guys don’t use maven like we do, nor do they use Eclipse for development.
OSGi is a runtime system. But OSGi failed to define a repository structure and dependency system for runtimes, until recently (Release 6+7). That’s why OH uses Karaf which defines a runtime dependency resolve system via Karaf features. Karaf defined its own repository format, but we do not use that correctly (we build a repo file once and deploy it with an OH installation. Very statically.)
The number above gets even smaller if you take into account how many projects use Karaf. That’s why we are pretty much alone with this setup.
Paths for the future
If we want to benefit from other projects, we need a setup similar to those projects. That means if we use bnd, we need to stop trying to re-create a setup like back in the PDE days.
I see several options:
Use Gradle instead of Maven which allows us to use BuildTools in Eclipse. That improves the control over the buildprocess like back in the PDE days, where Eclipse had the full control and not maven.
Change the Eclipse specific Oomph setup file to not use snapshots. Change maven to not use snapshots. If you want to develop bindings, you want to do that with the current released core. That also stops Eclipse and maven from downloading half the internet. More advanced users know the knobs to use snapshots if they want to.
Remove the openhab2-addons root maven file. Each bundle in there is independent. There is NEVER a need to build everything except for the distro and the CI system. And they can just iterate over directories to do so.
For maintainers: Yes that means removing the very useless BOM files. If each bundle is independent and correctly versioned (no snapshots anymore!) you do not need the bnd index generation.
For maintainers: Yes that also means no one-single-file karaf feature repo build anymore. If the distro wants that, the distro repo can assemble it.
Thanks for the clarification.
Therefore there is no pleasant end, a dead end road.
I wonder who decided to change the build and then get to a dead end?
I really don’t understand …
Or rather, who decides now which new road to take?
I don’t share a lot of the things said here. Yes, there are problems. None of these are really, really a problem.
Forever running builds: Build with maven one -> Done. Or: turn of “Build automatically” -> Done. Agreed, that is not the best solution, but works perfectly for me.
Debugging: Use the remote debugging. Works perfectly. With Eclipse. Eclipse also supports auto-formatting and everything else we need.
UI: I would prefer a Paper UI replacement, but I can’t see how the system is “unusable”. You can use text-files (what I would not recommend), you can use PaperUI for things and text for items, you can use PaperUI for everything if you don’t need tagging.
Installing “test”-bundles: Once we solved the “wrap” problem (which is in principle done, we just need some agreement on the way to provide the bundles), we can either install the dependencies manually or we can prodive a .kar which includes the feature.
OSGi works, maven works. I agree that maybe gradle would be “easier” than maven, but what would be the benefit if we change NOW? That should be discussed for OH3.
It does not work for me.
If I checkout+compile openhab2-addons using git+maven outside Eclipse (ok), then import the binding project I want to work on and then leave “Build automatically” ON I still have the problem of infinite build cycle.
If you have a proven solution with EclipseIDE where you can use “Build Automatically ON”, please share and I will be happy to update the IDE setup documentation accordingly.
I really really beg to differ. You, being in Germany, should be aware of those small, un-professional outfits like “Bundesagentur für Arbeit” or “Deutsche Bahn A.G.”. They put out tenders, asking in the project description explicitly for Eclipse as the whole project setup is standartized on that. Also, many insurance agencies (WWK and Allianz in Munich come to mind) explicitly ask for development experience in Eclipse.
I’m not defending Eclipse, which, in my opinion too, had its best days a few years earlier. I am also much more productive with IntelliJ.
I’m just slightly disturbed by your way of stating your opinions as the single truth.
At least, in this posting, you mentioned that those numbers came by in a “very un-scientific way”
A friend of mine just got rid of an eclipse based project and he is working for Bochumer Stadtwerke.
Especially insurances in Germany have super old tech and IT, Deutsche Bahn unfortunately as well in some parts. They still have separate systems for das deutsche Bahnportal and bahncard and sync customer databases via cronjobs. It’s no wonder that some software systems still rely on Eclipse.
It’s just that we need to be prepared for the future. The Android SDK with android studio basically self installs. Your first project is running within half an hour. Homeassistents python development environment is installed in minutes.
So we are really not competitive if our binding development setup takes an hour, downloads about 1000 different bundles during installation from different servers (fragile!), in 50% of the time the initial build fails, and you are forced to use the command line.
Apart from the fact that we have no marketing volunteers, only programmers. No blog post since 5 months. No community interaction from tech guys to users.
There’s no roadmap. People are doing their stuff although no planned action order is defined. Take the new UI for example. The UI has been written and will be introduced with OH3. But for OH3 we would break the Rest API of course (see my other post for the reasons). So the UI would need a heavy rewrite on the model and controller side. Could have been avoided with planning.
@J-N-K@David_Graeff
You can help me make the Remote debug work on Eclipse, hoping to unblock the situation.
I tested a few days ago VSCode with remote debugging, but I would like to use Eclipse.
Any help is welcome
I generally avoid discussions like this because I don’t rightly care (IDE, build system - it will ALWAYS change to something better). However, this statement is plain wrong. The only time “NEVER” should be used is when you say something like 'NEVER is NEVER valid". If you make a blanket statement like that, you just can’t envision a situation where YOU would use it.
Personally - I ALWAYS have use for access to existing addons while I’m developing an addon. The current example is that I’m developing the sony addon and I’m constantly looking at/running/modifying the sony-audio addon to compare. However, even beyond that - I’m always looking at other addon code and even modifying the code to try things that I then bring over to my addon.
Basically - there are valid reasons to want to compile other addons and “NEVER” doesn’t apply (and I want to continue it with whatever system going forward). Build time to me is never really a concern - it’s a one time issue and on my machine only takes a minute or two - not a concern…
You totally forgot the scale aspect. If we have 1000 add-ons in 5 years, do you really want to wait that 5 hours before the build of everything finished?
The addons2 repo contains independent bundles. And you can drag and drop them to your workspace at any time. But should the default be to build everything?
Hi guys, mabe someone could give me a hint.
Since yesterday I was trying to get a new devspace up and running, using eclipse.
Tried nearly 10 times with fresh Ubuntu VMs but following the new guide, the VM froze always during first run of eclipse at building io.rest.voice bundle.
Even a pure mvn clean install on command line froze my VM.
Any clue how to solve this?
Please don‘t come up with use VS Code instead…
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).
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)
