[netatmo] Added oauth2client to feature.xml

[clinique]

I faced not started oauth2client, preventing the NetatmoHandlerFactory to initialize while working on this.

This does not seem to hurt production that much because other binding may have required the oauth2client prior to Netatmo Binding.

I stumbled on this in the morning.

[wborn]

It shouldn't be necessary.

openhab-runtime-base depends on openhab-transport-http which depends on openhab-core-auth-oauth2client

If it is an issue for this add-on it's also an issue for all other add-ons using the oauth2client which would also need a fix.

[wborn]

The root cause is fixed with openhab/openhab-core#4012.

[jlaur]

@wborn - I'm wondering why the Netatmo binding works for me. It seems no other bindings have this feature explicitly declared, and I see this:

openhab> feature:list | grep oauth
openhab-core-auth-oauth2client                    x 4.1.0            x          x Uninstalled x distro-4.1.0             x

I guess it shouldn't really work? Or maybe it works because I already have a refresh token and haven't needed to go through the authorization flow for some time?

Additionally, multiple bindings declare openhab-transport-http while also declaring openhab-runtime-base:

grep -R "openhab-transport-http" -B 2 -A 2

Example:

openhab-addons/bundles/org.openhab.binding.deconz/src/main/feature/feature.xml

Lines 5 to 10 in ce1f366

	<feature name="openhab-binding-deconz" description="deCONZ Binding" version="${project.version}">
	<feature>openhab-runtime-base</feature>
	<feature>openhab-transport-http</feature>
	<feature>openhab-transport-upnp</feature>
	<bundle start-level="80">mvn:org.openhab.addons.bundles/org.openhab.binding.deconz/${project.version}</bundle>
	</feature>

Is it unneeded, if openhab-runtime-base depends on openhab-transport-http?

[wborn]

Unfortunately I have not found any info on how <feature dependency="true"> is supposed to work in the Karaf docs at https://karaf.apache.org/manual/latest/.

After a bit of testing it looks like Karaf installs such features on demand when a feature is installed that needs it. So it probably is only an issue for users who install JARs by copying them in the /addons dir and installing such JARs using the Marketplace.

Is it unneeded, if openhab-runtime-base depends on openhab-transport-http?

The openhab-transport-http feature has been preinstalled to prevent issues since OH 2.3, see openhab/openhab-core#344.

So it should be safe to remove openhab-transport-http from add-ons that still have this in their feature.xml.
There are probably also many add-ons that use the openhab-transport-http bundles without depending on this feature in their feature.xml.