Dear Community,
First of all, thanks that you try to develop the software for the upcoming challenges. I know that you spent tons of hours and lots of sweat to make OH the software it is!
Anyway, here at our institute we got the situation that the students need to finish their projects and therefore need a stable development environment. I see three options:
- A) we offer an old version of the old stack (ESH, old build tools, stable runtime) that people can write their addons and maybe rework it later to get it into the 2.5 version.
- B) we offer a step by step guide to build and compile the cli-way that people can continue their work on the functions and get these changes in their working software.
- C) we get the new IDE release and runtime release for OH 2.5 out in a few days.
Since C seems no option to me, because the current situation lasts for more than 6 months, I hope we can offer A and B for all the people out there. B seems pretty straight forward and maybe the old docs are still existing. I am not sure, if it is possible to offer a second version in the eclipse installer and how much effort that is. What do you think?
Best regards,
Jochen
For ease of development I would say that student projects are allowed to not use the “scope=provided” dependency annotation.
Let me explain:
Currently the cli way that is explained in the addons2 repo readme works. You can compile a single bundle with tests and checks. The resulting jar can be used in an OH instance. It also works in the distro demo project (which is not really openHab, because Karaf is not used).
But: it’s another story if you use dependencies especially ones with native libraries. It will also compile fine but it does not run in an OH instance, nor in the distro demo project. People need to know how to edit bndrun files, how to clean the maven or bnd cache on problems and they need to know how to wrap java dependencies as OSGi bundles. That’s a lot asked for students. The above recommendation will embed external libraries into a produced jar (fat jar) and helps with buildsystem problems.
Still Option 2 involves even more documentation to be written. The doc guys just recently overhauled the developer section, but the buildsystem document deserves more attention.
Option 1 is a lot of effort. Unfortunately the build script at any point in time always tries to download openhab core or eclipse smarthome from snapshots and that is very likely not compatible to whatever older revision of openhab2-addons you checkout. The git history therefore is a bit useless rn. So what would need to be done is to bundle an offline distro of OH 2.4 and rewrite the buildsystem. The issue is the p2 repos. Afaik they do not work offline.
So it’s option 2: the buildsystem document would need to have more sections and go into detail for all kind of situations. And a blog post would explain how to develop a new binding with one of the supported IDEs.
My 2ct.
