[transform.jinja] Properly use jinjava OSGi

[J-N-K]

Follow-up to #17356
Depends on openhab/openhab-osgiify#49

The former version did use the OSGiified bundle, but did still embed it. This properly adds it as a bundle dependency.

[jimtng]

Thanks for the fix! I copied it similar to many other bindings. I guess they should all be changed from compile to provided too? Example: allplay, ambientweather, volumio, openhabcloud, pollytts, etc. They're all set to compile

[J-N-K]

Thanks for the fix! I copied it similar to many other bindings. I guess they should all be changed from compile to provided too? Example: allplay, ambientweather, volumio, openhabcloud, pollytts, etc. They're all set to compile

It depends. The standard configuration is "compile is embedded". However, if there is a file noEmbedDependencies.profile dependencies are never embedded.

[jimtng]

What does this one apply to?

openhab-addons/bundles/pom.xml

Line 686 in 06b361c

<exists>noEmbedDependencies.profile</exists>

[J-N-K]

In the "normal" build (i.e. profile NOT activated) the maven-dependency-plugin is configured to execute the embed-dependencies job

openhab-addons/bundles/pom.xml

Lines 641 to 658 in 06b361c

	<execution>
	<id>embed-dependencies</id>
	<goals>
	<goal>unpack-dependencies</goal>
	</goals>
	<configuration>
	<includeScope>runtime</includeScope>
	<includeTypes>jar</includeTypes>
	<excludes>**/module-info.class</excludes>
	<excludeGroupIds>javax.activation,org.apache.karaf.features,org.lastnpe.eea</excludeGroupIds>
	<excludeArtifactIds>${dep.noembedding}</excludeArtifactIds>
	<outputDirectory>${project.build.directory}/classes</outputDirectory>
	<overWriteReleases>true</overWriteReleases>
	<overWriteSnapshots>true</overWriteSnapshots>
	<excludeTransitive>true</excludeTransitive>
	<type>jar</type>
	</configuration>
	</execution>

which unpacks all dependencies (except those defined in the dep.noembedding property) with the scope compile to the target/classes directory. Everything in that directory is later included in the .jar. This happens on the process-sources phase of the build.

The profile sets the execution phase for the embed-dependencies job to none and no dependencies are unpacked (and as a result nothing is embedded).

[J-N-K]

There seems to be an issue with resolving the new artifact because it has the same version. I would suggest to wait if that fixes by itself in the next 48 hours, otherwise I'll prepare a new version 2.7.2_0 to resolve that.

[J-N-K]

Why does it try to build mqtt.homeassistant tests? The build of the jinja transformation succeeded...

[jimtng]

Shouldn't this use the osgiified version too?

[J-N-K]

The difference between an OSGi bundle a a non-OSGi bundle is only the content of the MANIFEST.MF. In the case of an OSGi bundle the manifest contains a list of imported and exported packages, allowing the OSGi framework to decide what is needed to get this bundle running. What is done in the osgiify repository is essentially unpacking the .jar, examining the classes and creating a list of needed and provided packages, putting that together in a new MANIFEST.MF and finally package it again in a .jar. So from the classes contained, the osgiified bundle and the original bundle are the same. The additional statements are not used in the maven build, so we can stick to the original version.

The feature-verification checks if all required packages are available at runtime (i.e. it could wire all import statements to bundles). It takes the framework bundles (the openHAB core runtime bundles) and all bundles declared in the feature.xml to do this and there the additional statements are needed, otherwise it wouldn't know what is provided by the jinjava bundle, so we need to use the osgiified version.

[lsiepel]

Thanks for the details, this helped me to get a better understanding of how this fits together.

[lsiepel]

The empty file noEmbedDependencies.profile can be removed from the PR i guess, otherwise LGTM

[J-N-K]

No, the empty file is important. It activates the "no embedding" profile explained in #17358 (comment)

[J-N-K]

@jimtng If you need help in doing the same for the MQTT.homeassistant bundle, please ping me in that PR.

[jimtng]

Integrating Jinjava into mqtt.homeassistant and removing its dependency on the JINJA transform isn't quite as straight forward, it seems. I had a preliminary look but haven't investigated how to actually bypass the need for jinja transform (addon).

My cursory look shows that jinja is only referenced for the availability topics, and I'm unfamiliar with the rest of the homeassistant mechanism. It isn't heavily docmented, and I'm not a user of this binding.

I think @ccutrer is in a much better position to tackle this one.

[ccutrer]

I've been thinking on it ever since this PR was created. Basically the homeassistant piece just takes the Jinja template from the Home Assistant discovery JSON blob, and sets the "transformation" setting of the underlying MQTT value to it, so that it automatically uses the Jinja transformation. For most components this is fine, since it's a single variable we send to the template, and that's what a transformation can handle. But for some components(template schema light bulbs in particular, but I think some other pieces of more complicated components like climate) this doesn't work, because the templates expect to be able to access multiple values (r, g, b, x, y, color_temp, h, s, b, etc.). But for complicated lights we use proxy MQTT Value objects anyway with callbacks, so it's not a problem to use Jinjava directly there. It'll take some thinking on how to use it for the basic case without complicating all of the components with proxy values with callbacks.

[ccutrer]

Okay, I've got a gameplan now. I've written it up in #17374, and also linked from there the other issues that it will solve.