Hey developer community,
we need to find a solution for an easy to setup binding development.
The current distro uses the Demo-App approach that Markus established and that is also referred to from the openhab2-addons readme and developer documentation.
The problem with this Demo-App is, that it is not based on Karaf and therefore it’s not really related to the openHAB distro. Especially you can’t manually install features in your debug session, that you may need for testing your binding.
Starting Karaf from Eclipse for bundle development is not really supported (actually no IDE is really supported for this usecase by Karaf).
Start Karaf separately
What Karaf developers recommend instead is to just start a Karaf instance in debug mode (which allows a connection via JDWP - Java developer wire protocol).
With our bnd build we lost a good part of native Eclipse integration. We manually need to maven build the binding-under-development, push it to karaf and make sure that a connection via JDWP is established.
Thanks to bndtools however that changed recently. See https://github.com/mrulli/com.flairbit.examples.karaf-debug.
If we’d preinstall
with the distro, we would allow bndtools to “control” the OSGi container.
Our development workflow would need to be changed to:
- Start a karaf openhab instance
- Clicking on “Debug” in the IDE does the following automatically: builds the bundle, pushes it to karaf and establishes a remote connection.
bndrun file that we ship with such a developer-maven project for Eclipse would look like this:
# Override the default bnd launcher -runpath: biz.aQute.remote.launcher # Contact the remote agent on Karaf -runremote: test;\ shell = -1; \ jdb = 5005; \ host = localhost; \ # A developer could change that to his testing or production system agent = 29998; \ # Default port of the agent timeout = 10000
We only need to solve how to start and stop a karaf instance. Maybe instruct a developer to manually start it together with Eclipse, if the developer does not want to experiment with his production system. But even that is possible with this setup.
This is actually a huge advantage of OH in contrast to HomeAssistant et al, we can develop and test bindings on production systems if we want to, without restarting anything etc. How cool is that.
And: This solution should also work from Intellij and Visual Studio Code.
Terminology used in this post
Jar files: Compiled java classes bundled together with meta data in a zip file results in a jar file.
OSGi bundle: A jar file, but your java classes are prepared to be started/stopped by an OSGi framework.
OSGi framework: Multiple bundles orchestrated by OSGi standards+services.
Allows to dynamically add/remove jars + start/stop services.
Karaf: A solution that embeds an OSGi framework and provides a ton of extra features starting with a decent dependency system (“Karaf features”), Logging, Monitoring, Authentication, Database connections, Persistence support, Docker support, web management console, text console. openHAB uses Karaf because of its dependency management and its text console commands (we don’t really use more than that atm, which is another topic)
Drop Karaf and only use the karaf feature service in our own OSGi framework compilation in the openHAB distro as well as the binding development.