[bluetooth] Update bluez-dbus-osgi dependency

[lsiepel]

......

2. Another PR could be written to update the dependencies. Personally I am not sure if I can do that, so perhaps you can offer to do it?

Originally posted by @andrewfg in https://github.com/openhab/openhab-addons/issues/17035#issuecomment-2241162837

[lsiepel]

bluetooth.bluez

• uses: https://mvnrepository.com/artifact/com.github.hypfvieh/bluez-dbus-osgi that has an external dependency on dbus-java
• noticed the pom.xml declares bluez-dbus-osgi version 0.1.4 and the feature file declares 0.1.3
• the footer.xml declares bluez-dbus-osgi/0.1.3
• raised an issue to see if the 0.2.0 version can be release supporting newer dbus-java version

I wonder if we can remove the entry from the footer.xml and keep the dependency's closer to the binding. But I suspect other bluetooth bindings do rely on dbus-java so i guess we have to somehow seperate those.

[J-N-K]

The feature.xml and the footer.xml should be updated to 0.1.4. bluetooth (like mqtt and modbus) is a special case where one binding consists of several bundles, so the feature that defines the binding is not created from the feature.xml:

                  <fileset dir="${basedirRoot}/bundles">
                    <include name="*/src/main/feature/feature.xml"/>
                    <exclude name="**/org.openhab.binding.bluetooth*/**/feature.xml"/>
                    <exclude name="**/org.openhab.binding.modbus*/**/feature.xml"/>
                    <exclude name="**/org.openhab.binding.mqtt*/**/feature.xml"/>
                  </fileset>

but added in the footer.xml. The feature.xml in the binding folder is only used to let the karaf verification of the individual bundle pass.

[lsiepel]

The feature.xml and the footer.xml should be updated to 0.1.4. bluetooth (like mqtt and modbus) is a special case where one binding consists of several bundles, so the feature that defines the binding is not created from the feature.xml:

                  <fileset dir="${basedirRoot}/bundles">
                    <include name="*/src/main/feature/feature.xml"/>
                    <exclude name="**/org.openhab.binding.bluetooth*/**/feature.xml"/>
                    <exclude name="**/org.openhab.binding.modbus*/**/feature.xml"/>
                    <exclude name="**/org.openhab.binding.mqtt*/**/feature.xml"/>
                  </fileset>

but added in the footer.xml. The feature.xml in the binding folder is only used to let the karaf verification of the individual bundle pass.

Thanks. I just files a PR to align the versions.

[andrewfg]

suspect other bluetooth bindings do rely on dbus-java

AFAICT actually no. The Bluez is a bluetooth bridge thing that implements an abstract bluetooth bridge interface. Other bluetooth things may access their respective bridge via the methods of the abstract bridge interface. And they do not access any of the Bluez specific implementation details (i.e. dbus).

[hypfvieh]

AFAICT actually no. The Bluez is a bluetooth bridge thing that implements an abstract bluetooth bridge interface. Other bluetooth things may access their respective bridge via the methods of the abstract bridge interface. And they do not access any of the Bluez specific implementation details (i.e. dbus).

I'm not sure that this is true. Bluez itself exposes it's services to DBus which then can be used by anyone with proper permissions to interact with Bluez using DBus.

I never heard of any other way than DBus to access Bluez. Also the tools provided by Bluez itself (e.g. btmgmt) uses DBus to talk to the Bluez-Stack. All bluetooth tools I know for desktop environments on Linux also use DBus. Even tinyb, which was some bluez integration provided by Intel years ago (and abandoned for some time) was using DBus to talk to Bluez.

So I'm pretty sure using DBus is "the way" (maybe the only way) interacting with Bluez. How you achieve the communication with DBus is another thing. In case of Java it most likely is dbus-java (the original version 2.7.0 from 15 years ago or my fork of it). I never have seen any other implementation.

[andrewfg]

^ None of the other OH bluetooth sub bindings is importing dbus-java..