The method isRelevant looks if the Bundle has an addon.xml in the right place AND if this bundles jar is loaded directly from file.
If the bundles jar is in a kar, the bundle location is something like this: “@mvn:de.ibapl.openhab/de.ibapl.openhab.fhz4j/4.1.0.3-SNAPSHOT”.
Is there a need that the jar must be loaded directly from file and not from a kar also?
For debugging purpose I would welcome in addingBundle() a debug log statement if the bundle is not accepted - and why.
I tried to install the Eclipse/OH IDE, but the install hangs at 96% “Invoking dependency: unpack on org.openhab.ui” - I will give it a couple of hours mote to finish.
The maven build on 4.1 gives me this error message:
[ERROR] Failed to execute goal on project org.openhab.core.model.core: Could not resolve dependencies for project org.openhab.core.bundles:org.openhab.core.model.core:jar:4.1.0: Failed to collect dependencies at org.openhab.core.bom:org.openhab.core.bom.compile-model:pom:4.1.0 → org.eclipse.xtext:org.eclipse.xtext.generator:jar:2.32.0 → org.eclipse.xtext:org.eclipse.xtext.xtext.generator:jar:2.32.0 → org.eclipse.emf:org.eclipse.emf.codegen.ecore:jar:2.29.0 → org.eclipse.emf:org.eclipse.emf.codegen:jar:[2.22.0,3.0.0): No versions available for org.eclipse.emf:org.eclipse.emf.codegen:jar:[2.22.0,3.0.0) within specified range → [Help 1]
If you will name one of your features openhab-binding-xyz it will be showed as “trusted” xyz binding coming from distribution. It will make your testing easier, and you can always remove extra feature before publishing to marketplace.
I got a modified org.openhab.core.addon bundle compiled without isRelevant looking where the bundle is comming from - it solves the issue for me.
Beside from that the JarFileAddonService implements BundleTracker would be BundleAddonService a better name?
it sees all bundles that are loaded and only takes the ones with OH-INF/addon/addon.xml?
I would like to file a bug against this and provide a pull request with that changes…
With my BundleAddonService the installed addons appear twice at the thing add page.
Is there a reason why to handle the add-ons in a separate way - and not simply accept each bundle with “OH-INF/addon/addon.xml” regardless where it come from as add-on?
From my point of view this would be a cleaner solution.
There are some differences between these - the JarFileAddonService was intended for jars dropped into addons/ folder, hence hot-deployed through copy/upload to the installation. That’s why it is called “jar”, because file extension of extension bundles is .jar. If you removed filtering from this addon service you might actually run into situation where addon is reported by two addon providers - jar and kar (if you use it).
In case if your addon depend on external dependencies (which you decided not to wrap/embed within your addon jar) then in order to guarantee stable operation it has to be shipped as kar. Other way it will destabilize user environment cause it will require manual steps to prepare environment to get your addon activated. Even if your addon depends only on openhab-core you might still need a KAR file to declare dependency on non-essential core parts such as serial transport or oauth2 client.
but the KarafAddonService did not pick up my kar in the first place.
At a first glance at the sources it seems only to expect addons from OH.
So maybe I add my own AddonService to each of my bindings to register the binding.
Simply declaring “OH-INF/addon/addon.xml” in the kars binding jars seems unwanted.
I changed the feature names inside the kar to openhab-binding-fhz4j and openhab-binding-onewire4j.
Then the two bindings where picked up by the KarafAddonService. So far so good.
Both add-on where published under the “openHAB Distribution
Official bindings maintained by the openHAB project” - I don’t think that this is a good place.
But the drawback is: If I install/uninstall an addon my addons where uninstalled at the same time.
Currently I can live with it - but I think the addons should not listed under the “official” addons and not removed either.
Is this a bug or a feature?
You could use the JSON 3rd party marketplace, create a .json and enter the location in the settings. Then your binding will show up under “Other Add-ons” and install just fine. The json-format is like this:
[
{
"uid": "org-smarthome-automation-javarule",
"id": "javarule",
"type": "automation",
"version": "4.2.0-SNAPSHOT",
"author": "SmartHome/J",
"maturity": "stable",
"content_type": "application/vnd.openhab.feature;type=karfile",
"link": "https://docs.smarthomej.org/4.2.0-SNAPSHOT/org.smarthomej.automation.javarule.html",
"url": "https://docs.smarthomej.org/4.2.0-SNAPSHOT/org.smarthomej.automation.javarule-4.2.0-SNAPSHOT.kar",
"title": "SmartHome/J Java Rule Automation",
"description": "This addon allows writing rules in Java and provides support for code-completion for most IDEs. ",
"compatible_versions": "[4.2.0.0;4.2.999)",
"logger_packages": [ "org.smarthomej.automation.javarule" ]
},
...
]
Select the UID to be unique (i.e. prefix with com-github-aploese- or similar). This is the recommended way for 3rd party add-ons. If you create a PR and intend to add you new binding to the openHAB distribution, you can create a post in the Community Marketplace here in the forum, then your add-on will be installed from there.
