Closed lsiepel closed 1 month ago
bluetooth.bluez
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.
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.
The
feature.xml
and thefooter.xml
should be updated to 0.1.4.bluetooth
(likemqtt
andmodbus
) is a special case where one binding consists of several bundles, so the feature that defines the binding is not created from thefeature.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
. Thefeature.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.
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).
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.
^ None of the other OH bluetooth sub bindings is importing dbus-java..
......
Originally posted by @andrewfg in https://github.com/openhab/openhab-addons/issues/17035#issuecomment-2241162837