How to deploy test versions of add-ons to users

Development
1

I’m working on the Chromecast binding, with some relatively major refactoring (like replacing the library used to communicate with cast devices). I have limited testing opportunities because I only have one cast device, there are many different types and use scenarios out there. It’s become clear to me that I need some feedback along the way, I need to be able to somehow make my “test version” of the binding installable for select users.

I’m wondering what is the best/right approach. I can build a version of the binding that suits whatever OH version the user(s) use, so that’s not a problem. But, the binding have a non-OSGified dependency, the library used to communicate with the cast devices. Dependencies won’t normally be packed in the JAR when you build it.

I would like to avoid having to use Maven Shade plugin or similar to build a “combined JAR”, because that would mean both time to figure out how to get this right, and modifications to the bindings that would have to be reverted before creating a PR. At the same time, it’s not completely clear to me where non-OSGified dependencies are deployed in a normal OH installation either. Are they somehow packed with the bundles?

I would also prefer to not have to modify the binding so that it has a different name, preferably it should replace the official version when installed, and revert to the official binding when uninstalled.

I’m not very eager going down the KAR route, since they are “hard to build” and difficult to control. If the name/coordinates are the same as the official add-on, would a KAR even lead to the bundle in the KAR being used - instead of the one fetched via Maven?

My thinking is thus that it would either have to be a JAR or a marketplace add-on. But, in both these cases, I don’t know how a conflicting name with the official binding will behave, and I don’t know how to make sure that the user gets the non-OSGified dependency.

I can think of many potential ways to approach this, but this must be something that people have done many times before, so instead of figuring this out by trial and error - perhaps somebody can recommend something that actually works, with as few modifications to the binding itself as possible to make it work..?

2

I usually provide the jar in a zip with the dependency’s in separate jar’s

3

Will that work if they just drop those JARs in the addon folder? The dependencies aren’t bundles, so I wouldn’t think that they would do anything if dropped there?

edit: I’m trying to keep working on the Chromecast binding between other things, but sadly it’s slow, because all the other distractions make me “forget what I was doing”. I’ve also had to make a separate branch instead of basing it off your PR, because your PR branch is now so outdated that it won’t compile against latest Core (I still have your commits in there though).

4

that should work. The AmazonEchoControll hotfix was provided in a similar way. One zip file with all dependencies included. I just uninstalled the original binding, extracted everything to the addon folder and it works.

1 Like
5

Ok - I must admit that I don’t quite understand why it works, but I guess there’s no reason to dwell on that if it does :wink:

It all boils down to how Karaf works internally, and it must be somewhat different than I imagined then. I wonder who would “win” if you didn’t uninstall the original binding.

6

same to me,

I guess the whole way, how something is installed, is handled in 3 different ways. 1. Included addons, 2 Marketplace addons and 3. Addon folder based addons. Each way behaves a bit different.

e.g. for me the problem is… If I deploy my kar file into the addons folder, the dependencies are resolved, but no config dialog is resisted for this binding. If I deploy the same as a jar, like the openhab 4.3.x version, where all dependencies are included, the config dialog is visible. If the same binding is installed from the provided addons via webui, everything works too.

but anyway, I just want to mention that the jar/kar addon handling logic is a mess. But it works somehow :slight_smile:

7

As you know, I’ve looked at that before, so I know some of the pieces of the puzzle here, but not all. The reason no config dialog is present is quite simple, OH’s add-on handling “expects” KARs to be official add-ons only - so the addon.xml from the KAR file isn’t parsed. The KAR handling in general is quite broken, but I’ve not been able to figure out how to make it work properly, because there are some assumptions made in the code that are “unfortunate” - and trying to change that, might break “everything”.

In addition, I still don’t know fully how Karaf works, they aren’t exactly great at documentation - which makes it ever harder to figure out how things could be solved.

Basically, everything is about bundles, but the bundles don’t “know” if they belong to a feature or not, and a feature don’t “know” if it comes from a KAR or not. Trying to figure out how to treat things properly, when to do what, when you deal with a lot of entities that you have way too little information about, is hard. When you drop a KAR, its content will be “imported”, including any features, but you have no control over what is actually being used. Karaf might figure out that it should resolve the feature dependency from a KAR to use bundles from Maven for example… there’s just no “good way” that I’ve found to link these things together and treat them as “one package”.