Test all features, if they are correctly installable on the core runtime

[kaikreuzer]

When testing the Karaf distro, I had some trouble with dependencies that were not available for some features (I remember Hue and Sonos). We will have to check all of them once, if they can be installed correctly.

[maggu2810]

Sure, that should be done. But this is for me not a blocker at all, but a place for improvements. I would also prefer to further separate the runtime features.

[kaikreuzer]

But this is for me not a blocker at all, but a place for improvements.

Well, if you cannot install the Hue or Sonos binding on OH2 anymore, this would be quite a hard regression which would upset quite some people, so I'd rather want to avoid this.

[maggu2810]

I prefer to solve as much as stuff as possible. But what is the current way to install the Hue or Sonos binding on OH2? I used Karaf a long time, so I am not familiar with the current mechanism. IIRC the bundles have to be dropped to the addon directory. This mechanism (deploy directory for Karaf ATM) should still work. Install stuff using Karaf features is something new, that no person know about. So, I do not see what we will break if some features does not work at day zero. Just to be clear: I do not want to introduce non working stuff. But you asked "Do they make sense to you" and so I want to state, that IMHO this is no blocker for me, just something that could be optimized.

[kaikreuzer]

IIRC the bundles have to be dropped to the addon directory. This mechanism (deploy directory for Karaf ATM) should still work.

Correct, but we just as we would not build a demo distro anymore, we also won't build an addons.zip - hence there is nothing to put into the addons folder :-)

And sticking to the addons would defeat the whole sense of switching to Karaf and maintaining Karaf features for all the addons.

[maggu2810]

I learned that there is a automatic feature validation that could be used. Here two examples:

• https://github.com/ANierbeck/Karaf-Cassandra/blob/master/Karaf-Cassandra-Feature/pom.xml#L56-L85
• https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax-web-features/pom.xml#L96-L140

[kaikreuzer]

Sounds interesting, it would be cool to have that verified within the build itself.

[maggu2810]

I started feature verification for shk. It seems to be working, as features could be resolved successfully and some others are complained about missing dependencies (that are really missing). So perhaps you can have a look there.

[maggu2810]

I started some changed: https://github.com/openhab/openhab2/compare/karaf...maggu2810:karaf-features?expand=1

• openhab-runtime-compat1x => openhab-misc-compat1x: it is nothing that needs to be installed for OH2 only, so misc is perhaps a better place. Or do you want to "hide" all stuff without a function on its own (a comprehensible reason). Don't know why I have choosen runtime before.
• All openhab addons should depend on a openhab base runtime, that will be (in future) the minimal subset of bundle that identify a OH2 system

The verification is already running and identify improvements / TODOs.

[maggu2810]

• "openhab-binding-dmx" needs "org.eclipse.osgi.framework.console". This should be changed to be optional, so the binding could also be used on other OSGi frameworks
• "openhab-persistence-logging" needs "ch.qos.logback.classic". I am not familar with that binding, but could it use the slf4j-api instead the logback one
• there are bundles that needs the compat1x bundle but are written for / ported to OH2. This should be checked if this is really necessary
• the branch (see above) contains a verified (all but the two mentioned the lines above) addons feature set (but is using shk feature sets)
• the shk repo is using a much more cleaner oh2 runtime feature set

Perhaps this helps you

[kaikreuzer]

Or do you want to "hide" all stuff without a function on its own (a comprehensible reason). Don't know why I have choosen runtime before.

Yes, that's what I would like to do! These are dependencies that are installed when installing an "add-on", but they are no valid installable feature on their own. So we should use some other name than "misc". "runtime" sounds like a good choice ;-)

there are bundles that needs the compat1x bundle but are written for / ported to OH2. This should be checked if this is really necessary

Can you name them? I am only aware of astro1, but this is intentional, as the OH1 version has a larger feature set than the OH2 version.

[maggu2810]

IIRC:

• mvn:org.openhab.binding/org.openhab.binding.freebox/${project.version}
• mvn:org.openhab.binding/org.openhab.binding.rfxcom/${project.version}
• mvn:org.openhab.ui/org.openhab.ui.cometvisu/${project.version}
• mvn:org.openhab.addons.io/org.openhab.io.myopenhab/${project.version}

[kaikreuzer]

All these are ${project.version} and not ${oh1.version} - so they are already from OH2. So your point is that they still reference the compat layer as a requirement. Really?

[maggu2810]

Yes, they are openHAB 2 addons and need the compat layer for openHAB 1 bundles

freebox

• org.openhab.library.tel.items

rfxcom

• org.openhab.core.binding

cometvisu

• org.openhab.core.types

myopenhab

• org.openhab.core.scriptengine.action

[kaikreuzer]

Good catch - I have fixed all of them with https://github.com/openhab/openhab2/pull/510.

[kaikreuzer]

"openhab-binding-dmx" needs "org.eclipse.osgi.framework.console". This should be changed to be optional, so the binding could also be used on other OSGi frameworks

Addressed with https://github.com/openhab/openhab/pull/3503

"openhab-persistence-logging" needs "ch.qos.logback.classic". I am not familar with that binding, but could it use the slf4j-api instead the logback one

This indeed uses the logback classes for its implementation and heavily relies on that. This is definitely not compatible, so we would have to leave that out of the distribution. Should be ok, I don't think that too many people really use it.

[maggu2810]

I a logback bundle could coexist with the normal logging, we could add a logback artifact for this feature (persistence-logging) only. But don't know if this is relevant.

[kaikreuzer]

Sounds like a possibility we could briefly test at least.

[maggu2810]

IMHO feature implemented by #519 As stated, it is disabled (but working) until the current master is merged (at least #510).

As stated here that two addons are currently deactivated:

• "openhab-binding-dmx" needs "org.eclipse.osgi.framework.console". This should be changed to be optional, so the binding could also be used on other OSGi frameworks [see openhab/openhab#3503]
• "openhab-persistence-logging" needs "ch.qos.logback.classic". I am not familar with that binding, but could it use the slf4j-api instead the logback one [test logback integration for feature]

[kaikreuzer]

FTR: #519 is merged. #510 is merged as well.

• "openhab-binding-dmx" - openhab/openhab#3503 is merged, so this can be added again.
• "openhab-persistence-logging": It cannot use the slf4japi, it needs the ch.qos.logback.classic bundle. We could add this dependency in its feature definition.

[maggu2810]

510 is merged into the master, but not into the karaf branch.

To enable the verification it need to be merged in the karaf branch.

[maggu2810]

See #521

[maggu2810]

This should be solved by #523 and #539 now.

[kaikreuzer]

FTR, I just tested the installation of all add-ons and came across a few problems that should be addressed with https://github.com/openhab/openhab/pull/3549.

[maggu2810]

Missing imports in the manifest file are not checked by the feature verification and this seems correct to me. That should be done at build time (maven-bundle-plugin / bndtools) or by the Eclipse IDE for Manifest-first approach.

[kaikreuzer]

Yes, that's also ok for me, but it means that we need to manually check it for the moment :-)