I am currently working on the org.openhab.core.io.rest.core bundle, however I am failing to deploy it into my test openHAB system.
openhab> bundle:list org.openhab.core.io.rest.core
START LEVEL 100 , List Threshold: 50
ID │ State │ Lvl │ Version │ Name
────┼────────┼─────┼────────────────────┼─────────────────────────────────────────────────────────────────────────────────────
177 │ Active │ 80 │ 4.1.0.202307231721 │ openHAB Core :: Bundles :: REST Interface :: Core
openhab> bundle:update 177 file:///usr/share/openhab/org.openhab.core.io.rest.core-4.1.0-SNAPSHOT.jar
openhab> bundle:list org.openhab.core.io.rest.core
START LEVEL 100 , List Threshold: 50
ID │ State │ Lvl │ Version │ Name
────┼───────────┼─────┼────────────────────┼──────────────────────────────────────────────────────────────────────────────────
177 │ Installed │ 80 │ 4.1.0.202307241035 │ openHAB Core :: Bundles :: REST Interface :: Core
When I not either start the bundle or re-start openHAB, I get:
org.osgi.framework.BundleException: Could not resolve module: org.openhab.core.io.rest.core [177]
Unresolved requirement: Import-Package: org.openhab.core.addon; version="[4.1.0,5.0.0)"
But the missing bundle is there:
openhab> bundle:list org.openhab.core.addon
START LEVEL 100 , List Threshold: 50
ID │ State │ Lvl │ Version │ Name
────┼────────┼─────┼────────────────────┼─────────────────────────────────────────────────────────────────────────────────────
150 │ Active │ 80 │ 4.1.0.202307231718 │ openHAB Core :: Bundles :: Add-on XML
Try packages:export | grep org.openhab.core.addon to see if this package is exposed by anything. It looks to me that you miss a addon bundle itself, the model bundle might ship just DTO classes
The exception makes sense if you deploy a 4.1.0 bundle in a 4.0.0 system as it does not have 4.1.0 bundles. Try deploying it in a 4.1.0 snapshot runtime instead.
I had a look at the available package versions, and noticed that I had 4.1.0~20230724092152-1 installed, which I then noticed is a usual scheme for openHAB.
Checking the available snapshot packages, I decided to try 4.1.0~S3562-1 which works fine.
/cc @Benjy Seems like there was something going on with out Linux packages …
4.1.0~20230724092152-1 can only happen if a Linux package build was triggered manually. It will adopt the name 4.1.0~S####-1 if it’s tied to a particular openHAB build. It’s likely that the first 4.1.0 snapshot was built at a strange time when everything else was changing to version 4.1.0. It is rather strange that this build succeeded.
S3562 was the first 4.1.0 build to be triggered by our CI processes and looks to be behaving correctly… did APT/DNF offer S3562 as an upgrade over 20230724092152?
I triggered a build manually because it failed because the build config needed to be reconfigured to download 4.1.0 instead of 4.0.0.
AFAIK the .deb package version is irrelevant to all the Java code. The bundle versions are based on the info in the manifests inside the JARs. So if it was some issue with a certain build, it would impact any packaging method (.zip, .deb, .rpm, Docker etc.).
Thanks @wborn, yes the .deb packaging is irrelevant to Java code and also the included distro scripts. So as you say the original problem is likely to do with the distro build.