Migrating addons to v4.0 - list of necessary changes available?

Development
1

I’m maintaining a handful of bundles that I would like to migrate/upgrade to Openhab 4.0.

Does there exist a simple list of necessary changes somewhere that I didn’t stumble upon yet?

Regards

2

In most cases there should be no need to adjust something.

  • If you want to “future-proof” your add-ons, you should make them accept QuantityType AND DecimalType for Number channels (where that applies).
  • If you do color conversions, you can check if you can use the new ColorUtil class from core.
  • You can check if you can make use of Java 17 improvements like pattern matching (if (foo instanceof BarType bar) { bar.method(); ... } instead of if (foo instance of BarType) { BarType bar = (BarType) foo; bar.method(); ... }. This is especially useful if you use the casted value more than once, because if avoids the need to assign a new variable.
  • If there are no null annotations: Add them. They are very good at preventing NPEs. If you come across an issue where you are unsure: feel free to ask.
  • Add tests, we have had quite some issues with regressions that could have been avoided if we had better tests, especially in openhab-addons.
2 Likes
3

Thanks Jan,

The only thing I had made a mental note about was the new addon.xml. But that isn’t required?

Regards

4

That is indeed required, but it should already have been done for all add-ons. Or do we talk about 3rd party/not merged add-ons? In that case the binding.xml needs to be replaced with an addon.xml.

5

Actually both, but now I see that the official addons already have this added. Then I’ll just add it for the 3rd party addons as well.

Can the old binding.xml co-exist with the new addon.xml, making the binding binary usable on both OH 3 and 4 (of course unless I am using Java17 features or depend on newer versions of other bundles), or do I need to provide 2 binaries? And 2 marketplace postings, or can it be the same?

Thanks in advance,
Arne

6

It’s still possible to create a jar for both 3.4 and 4.0, although this might change in the future, and already can be an issue in some cases. To build a jar for both versions start with the openHAB 4.0 branch and Java 17. But compile with maven with the following options:

mvn clean install -pl :<your binding> -Dohc.version=3.4.0 -Doh.java.version=11 -Dkaraf.version=4.3.7

This will compile against openHAB version 3.4.0 with Java 11 and an older Karaf version. (I included the clean to make sure I get Java 11 compatible class files).

You will also need to add both an addon.xml and binding.xml. They don’t conflict. The first is for openHAB 4.0 and the later for 3.4.0.

Some restrictions apply:

  • The binding code should not contain any Java code not compatible with Java 11, otherwise it won’t compile.
  • The DecimalType class constructor has been changed in 4.0. You need to pass a Number class, and not a primitive (e.g. double). A primitive will compile with 3.4.0, but it will cause a crash on openHAB 4 because the constructor with the primitive variable has been removed.
  • Some new functionally added in openHAB 4 is not present in openHAB 3.4.0, but the maven compile will cause it to fail anyway when compiling against older openHAB versions. But this might be an issue when starting with an existing binding from the openHAB 4 branch.
  • If you use Eclipse (and possible other IDEs) make sure you either close Eclipse or disable build automatically when running the maven command (specially when using mvn clean). Otherwise Eclipse might also start recompiling during your maven build and generate Java 17 class files. This will results in invalid code/jar files.
3 Likes
7

Hi Hilbrand,
just followed your advice to compile a binding for openHAB 3.4.x but without success.
Maven succeded for openHAB 4.0 but compiling for 3.4.0 like shown above results in the following error:

[ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.3.7:verify (karaf-feature-verification) on project org.openhab.binding.lgthinq: Feature resolution failed for [openhab-binding-lgthinq/4.0.0.SNAPSHOT]
[ERROR] Message: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=openhab-binding-lgthinq; type=karaf.feature; version=4.0.0.SNAPSHOT; filter:="(&(osgi.identity=openhab-binding-lgthinq)(type=karaf.feature)(version>=4.0.0.SNAPSHOT))" [caused by: Unable to resolve openhab-binding-lgthinq/4.0.0.SNAPSHOT: missing requirement [openhab-binding-lgthinq/4.0.0.SNAPSHOT] osgi.identity; osgi.identity=org.openhab.binding.lgthinq; type=osgi.bundle; version="[4.0.0.202305242103,4.0.0.202305242103]"; resolution:=mandatory [caused by: Unable to resolve org.openhab.binding.lgthinq/4.0.0.202305242103: missing requirement [org.openhab.binding.lgthinq/4.0.0.202305242103] osgi.wiring.package; filter:="(&(osgi.wiring.package=com.fasterxml.jackson.annotation)(version>=2.14.0)(!(version>=3.0.0)))"]]

Any hint how to solve this ???

8

It fails due to jackson dependency. Make sure that thinq feature declares dependency on it and have a proper version in pom.xml for it.

9

Thanks Łukasz, I will check…

10

Hmm, compared to other bindings, this looks ok in pom

    <dep.noembedding>jackson-core,jackson-annotations,jackson-databind</dep.noembedding>
  </properties>

  <dependencies>
    <dependency>
      <groupId>com.fasterxml.jackson.core</groupId>
      <artifactId>jackson-core</artifactId>
      <version>${jackson.version}</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>com.fasterxml.jackson.core</groupId>
      <artifactId>jackson-annotations</artifactId>
      <version>${jackson.version}</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>com.fasterxml.jackson.core</groupId>
      <artifactId>jackson-databind</artifactId>
      <version>${jackson.version}</version>
      <scope>compile</scope>
    </dependency>

Compiles ok at 4.0.0.

11

To me it looks like compile vs runtime version difference. Check in OH4 console what la -l|grep jackson gives you. Version which will be found there should match one used during compilation (${jackson.version}). Then binding should resolve just fine.

This check is there to assure that you do not get incompatible version of jackson.

12

Not sure if setting the java version does this, but I set maven.compiler.source and maven.compiler.target to 11 when I do marketplace builds to make them complatible. Plus ohc.version and karaf.

13 
                           _   _     _     ____
   ___   ___   ___   ___  | | | |   / \   | __ )
  / _ \ / _ \ / _ \ / _ \ | |_| |  / _ \  |  _ \
 | (_) | (_) |  __/| | | ||  _  | / ___ \ | |_) )
  \___/|  __/ \___/|_| |_||_| |_|/_/   \_\|____/
       |_|       4.0.0-SNAPSHOT - Build #3480

Use '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
To exit, use '<ctrl-d>' or 'logout'.

openhab> la -l|grep jackson
 30 x Active   x  80 x 2.14.1                 x mvn:com.fasterxml.jackson.core/jackson-annotations/2.14.1
 31 x Active   x  80 x 2.14.1                 x mvn:com.fasterxml.jackson.core/jackson-core/2.14.1
 32 x Active   x  80 x 2.14.1                 x mvn:com.fasterxml.jackson.core/jackson-databind/2.14.1
 33 x Active   x  80 x 2.14.1                 x mvn:com.fasterxml.jackson.dataformat/jackson-dataformat-yaml/2.14.1
 34 x Active   x  80 x 2.14.1                 x mvn:com.fasterxml.jackson.datatype/jackson-datatype-jsr310/2.14.1


                           _   _     _     ____
   ___   ___   ___   ___  | | | |   / \   | __ )
  / _ \ / _ \ / _ \ / _ \ | |_| |  / _ \  |  _ \
 | (_) | (_) |  __/| | | ||  _  | / ___ \ | |_) )
  \___/|  __/ \___/|_| |_||_| |_|/_/   \_\|____/
       |_|       3.4.3 - Release Build

Use '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
To exit, use '<ctrl-d>' or 'logout'.

openhab> la -l|grep jackson
 29 x Active   x  80 x 2.12.7                  x mvn:com.fasterxml.jackson.core/jackson-annotations/2.12.7
 30 x Active   x  80 x 2.12.7                  x mvn:com.fasterxml.jackson.core/jackson-core/2.12.7
 31 x Active   x  80 x 2.12.7.1                x mvn:com.fasterxml.jackson.core/jackson-databind/2.12.7.1
 32 x Active   x  80 x 2.12.7                  x mvn:com.fasterxml.jackson.dataformat/jackson-dataformat-yaml/2.12.7
 33 x Active   x  80 x 2.12.7                  x mvn:com.fasterxml.jackson.datatype/jackson-datatype-jsr310/2.12.7
14

It looks good, 2.14 is a valid version for OH 4.0. Can you try adding below dependency to thinq binding feature?

		<feature dependency="true">openhab.tp-jackson</feature>

Looking at thinq PR I see that declared feature already depends on openhab-runtime-base which should bring jackson. I am not 100% sure of why it is not considered as a valid wiring candidate.

15

Excuse me, have not worked with dependencies, whee do I add it ?

16

You need to add it to feature.xml file cause error you see in your build comes from feature validation which assures that binding will install fine at runtime:
This is file/place where you need to append extra dependency:

You also need to double check if your parent version is consistent:

It often happens that during git rebase maven parent project reference stays behind actual checkout version.

1 Like
17

Thanks Lukasz, finally got it to compile.
I deleted

    <!-- <bnd.importpackage>!net.sf.ehcache.*,!net.spy.*,!sun.nio.ch.*,!com.fasterxml.jackson.*</bnd.importpackage> -->
    <!-- <bnd.importpackage>!com.fasterxml.jackson.*</bnd.importpackage> -->

and

    <dep.noembedding>jackson-core,jackson-annotations,jackson-databind</dep.noembedding>

from pom.xml. Now have to check, if it is still working :wink:

18

Thanks again Łukasz, I have been able to finally build versions running at openHAB 3.4.x and openHAB 4.0 (latest SNAPSHOT)

Only thing I now have to do is to rename the openHAB 3 version, as it still has 4.0.0-SNAPSOT in its name.

2 Likes