Hi,
I’m the maintainer of the Viessmann and Glowmarkt API bindings, which are built out-of-tree. These bindings are distributed as .kar archives. Recently I updated them to work with OH 4. I found that users weren’t able to add any things for the binding, due to code in the CommunityMarketplaceAddonService which assumes a specific naming pattern convention, namely that the addon file is named something like
foobar.bindingId-major.minor.revision.kar
where bindingid has to be the same as the binding id reported in the binding.xml - and this is used as the filter on the add things page, thus preventing my users from using the binding.
So, I dutifully renamed my binding file as that seemed the path of least resistance.
Then, I find that something else has changed, not sure what exactly, but previously before OH4 I was able to test my binding in development by just dumping it into the addons/ folder, and it would just work. Now, it seems that for whatever reason, KarafAddonService decides to uninstall my binding at startup because it is not in addons.config
Also, fine, annoying but I can update the properties in karaf. But there also seems to be code in there that does things with filenames and addon ids, which I don’t pretend to understand. However it does seem to require that the feature name is openhab-binding-foo, and make assumptions about the author of the binding being OpenHAB.
I now note that when my binding is installed from the marketplace, it appears in both “OpenHAB Distribution” as a binding with a blue OpenHAB tick (albeit with broken links), and also as an installed binding in “Community Marketplace” where I expect. I could be wrong, but I’m pretty sure that didn’t happen previously.
Q: Is/are these bugs in OpenHAB, or am I doing something wrong? Do other marketplace binding maintainers have these problems? I had a quick look, but it seems most people are distributing as jars and/or SNAPSHOT builds which might avoid these pitfalls. How are people installing their bindings for development?