Binding build to addons folder - only works on some PCs?

Hello,

I have OpenHAB 2.5.6 installed on two Windows 10 PCs. On PC #1, I built and copied to addons a binding I modified. Watching the logs, I see that the binding is updated.

I copy the jar file to PC #2 and place it in the addons folder. Watching the logs, I do not see that the binding is updated, and the binding continues to behave like the original binding.

One difference between the two PCs is that PC #1 uses Oracle Java to build, and is using Oracle Java for running OpenHAB. PC #2 is running Zulu Java.

Any ideas why the jar in addons folder doesn’t work on PC #2?

It might be the old jar is still in the cache and therefore it might not work. Best stop openHAB and clean the cache/tmp.

Here are the steps I did:
Fresh install of OpenHAB 2.5.6
Start.bat
Standard
Paper UI
Add the “release” CM11a binding via the WebUI
Drag my modified, built, and working on PC #1 .JAR of CM11a binding to addons folder
Inbox-> + -> CM11a binding: I see two of every “thing” available (this does not happen on PC #1 )
command line logout
delete cache and tmp in userdata
start.bat
standard
Paper UI
Inbox-> + -> CM11a binding: I still see two of every “thing” available
Try to add thing: Error popup “ERROR: 503 - Service unavailable”

If I do the steps above but try to place my JAR in addons without first installing the “release” add-on, I get this:

14:21:42.017 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/C:/OpenHAB2/addons/org.openhab.binding.cm11a-2.5.7-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.cm11a [210]
Unresolved requirement: Import-Package: gnu.io; version="[3.12.0,6.0.0)"

    at org.eclipse.osgi.container.Module.start(Module.java:444) ~[org.eclipse.osgi-3.12.100.jar:?]
    at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[org.eclipse.osgi-3.12.100.jar:?]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.4]

I’m sure if I follow your steps and can give an indication of what happens. But installing 2 versions of the same binding in general doesn’t work very well and can cause strange behavior.

The reason the jar doesn’t work is because the binding has additional dependencies that need to be installed. You need to compile a kar file of it. The kar file will include the feature.xml of the binding that is used to install the dependencies. You can create a kar file on the command line with maven from the base of openhab-addons directory:

mvn karaf:kar -pl :org.openhab.binding.cm11a

This will build a .kar file in the target directory of the binding. It gives some warnings, but should still build the kar file. Drop this kar file in the addons directory just like you did with the jar file.

You need to make sure your branch is in sync with 2.5.7-SNAPHOT (I assume it is, given you build for that version) and it seems you need to build a jar first (use install instead of karaf:kar) That should work without having to make any modifications.

I don’t know what version I’m in sync with. I did the eclipse install per the instructions earlier today. How do i get in sync with 2.5.7-Snapshot?

My OpenHAB installation is 2.5.6, do I need to switch it to snapshot?

If you installed today you have 2.5.7-SNAPSHOT. You don’t need to switch to snapshot.

OK, I hardcoded the version in feature.xml to 2.5.7-SNAPSHOT in two places, ran mvn install and mvn karaf:kar, and the resulting kar file when placed in addons worked. Thanks!

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.