OH 4.0: Bundles must use GSON 2.9.1 instead 2.8.x

[stefan-hoehn]

As discussed here https://community.openhab.org/t/openhab-4-0-snapshot-discussion/142322/69 there are several bundles that use the unsupported gson version but should use GSON 2.9.1 instead

The following bundles were currently identified to at least need to be updated (I added the code owners here)

• dbquery @lujop
• influxdb @lujop
• watsonstt @GiviMAD
• org.openhab.binding.bluetooth.generic @cpmeister

Can the code owners please provide fixes as it currently breaks 4.0 (at least on my side ...)

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/openhab-4-0-snapshot-discussion/142322/73

[jlaur]

For reference: openhab/openhab-core#2994

And previous upgrades:

• Bump gson from 2.8.5 to 2.8.9 in /bundles/org.openhab.binding.dbquery #12798
• Bump gson from 2.8.5 to 2.8.9 in /bundles/org.openhab.persistence.influxdb #12772

[stefan-hoehn]

As soon as all the four updates have been merged I am happy to pull the latest snapshot and I will provide input for that at https://community.openhab.org/t/oh4-on-buster/142645/21 (or/and) here.

[wborn]

Everything is merged now!

[stefan-hoehn]

Thank you, Wouter, and I did test it this morning already. Most likely, these dependencies are gone now but my 4.0 system with the restored database from 3.4 is still not starting up. I will follow up on that topic in the related thread.

[stefan-hoehn]

@wborn @jlaur I can finally confirm that the problem is now fixed. Also see https://community.openhab.org/t/oh4-on-buster/142645/30

[clinique]

@wborn : would it be possible to go to version 2.10 in regard of OH4 so we can take advantage of records ?

[wborn]

lsp4j requires a 2.9.x version so it's only possible when multiple versions are provided:

org.eclipse.lsp4j_0.19.0.v20221118-0359 [131] requires:
-------------------------------------------------------
osgi.wiring.package; (&(osgi.wiring.package=com.google.common.base)(&(version>=30.1.0)(!(version>=31.0.0)))) resolved by:
   osgi.wiring.package; com.google.common.base 30.1.0 from com.google.guava_30.1.0.jre [36]
osgi.wiring.package; (&(osgi.wiring.package=com.google.gson)(&(version>=2.9.1)(!(version>=2.10.0)))) resolved by:
   osgi.wiring.package; com.google.gson 2.9.1 from com.google.gson_2.9.1 [35]
osgi.wiring.package; (&(osgi.wiring.package=com.google.gson.annotations)(&(version>=2.9.1)(!(version>=2.10.0)))) resolved by:
   osgi.wiring.package; com.google.gson.annotations 2.9.1 from com.google.gson_2.9.1 [35]

[J-N-K]

Do you know if there really is an issue with 2.10? Looking through previous requests to increase the version range in their repo seems to indicate they are anxious that google might introduce breaking changes and use a very conservative range because of that.

[wborn]

It usually works but if we only add 2.10.x, Karaf feature validation will fail and the lsp4j bundle will fail to get started because the version of the package it depends on is not there. So either both versions need to be deployed, a newer Xtext/LSP4J that has updated dependencies is used... or we create an OH version with updated manifest.

[J-N-K]

Yes, that is what I was looking at. If it's really only the manifest, we could create an OH specific version with updated manifest.