<@U0F3291QE> Do you see this warning in your maven...

# tornadofx

[kastork]

@edvin Do you see this warning in your maven OSGI projects?

w: Some JAR files in the classpath have the Kotlin Runtime library bundled into them. This may cause difficult to debug problems if there's a different version of the Kotlin Runtime library in the classpath. Consider removing these libraries from the classpath or use '-Xskip-runtime-version-check' to suppress this warning
w: /Users/kirk/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-osgi-bundle/1.1.2-5/3d90538db8e39a17c9125184cd96ff60275e0d0/kotlin-osgi-bundle-1.1.2-5.jar: Library has Kotlin runtime bundled into it

[kastork]

ah, need to prevent sub-projects from bundling kotlin

[edvin]

Yes indeed 🙂 So you're all good?

[kastork]

I think so, still working through how all this OSGI packaging works with these plugins

[kastork]

Hopefully this will result in a gradle version of your osgi chart example

[kastork]

but it is after 7, need to put it down and start my day-job

[edvin]

Oh cool! That will be a nice addition to the templates!

[kastork]

@edvin https://github.com/kastork/tornadofx-osgi-demo it is a start anyway. I feel like I'm having to do too much fussing around with the jar manifests - like there must be a better way.

[edvin]

Are you doing the logging things because those classes are only used indirectly and cannot be detected by the osgi plugin? I think this is the way to go, and in my opinion this shows how much work it is to actually set up an OSGi project. However, if we can do that hard work only once, it's still worth it.

[kastork]

This section of the plugin's readme was my guide here. https://github.com/renatoathaydes/osgi-run/blob/master/README.md#solving-unresolved-constraint-errors

[kastork]

I've never really worked with OSGI before, but I recognize the value of it. Doing this partly to learn, and partly to convince myself one way or the other to use it in a real project.

[edvin]

Good exercise. I'm curious about your conclusion at the end of it.

[kastork]

part of why I'm considering it is because my group has floated the notion of packaging our tools as Eclipse plugins

[kastork]

new push - it now does everything your example does. However I still feel like each bundle has too much going on in the jar manifest. Any ideas how to put this yak shaving out back where it belongs?

[edvin]

If yak shavings = runOsgi then I think that's the best place for it. If the gradle plugin reads bndfiles it could be put there, but that just adds one more file to keep track of.

[edvin]

In OSGi, every bit of magic is in the manifest, so this seems natural. Unfortunately, OSGi isn't just a dance on roses. It does require some workarounds for issues like this.