RFC: Does anyone still care about these bundles?

[io7m]

I'm considering dropping support for these bundles, partly due to this bug:

https://github.com/LWJGL/lwjgl3-osgi/issues/12

... and partly due to this now existing:

https://github.com/apache/felix-atomos

At the time these bundles were created, there was nothing in the way of interop for OSGi and JPMS. These days, any OSGi container supporting Connect should be able to depend on loaded JPMS modules. There doesn't seem to be a great reason to keep these bundles around.

[Angular-Angel]

I'm trying to use them right now, they seem like they should be very helpful for me.

[io7m]

If you're willing, and have the time, it might be worth seeing how well the existing LWJGL jar files (as in, not these OSGi bundles) work with Felix Atomos. It should be possible to access the LWJGL modules as if they were OSGi bundles if your OSGi framework is instantiated with a ModuleConnector: https://github.com/apache/felix-atomos#creating-a-framework

[Angular-Angel]

Well, I got my thing working with your bundles. I'll take a look at using atomos instead, and see if that works for me? :/

[io7m]

Yep. I mean... We know these bundles work, but the problem is that they fracture the userbase into those that use JPMS modules and those that use OSGi bundles. It means you can't write a library that uses LWJGL that supports both deployment cases, because you have to pick one of those two as a dependency. If it turns out that it's possible to use the standard LWJGL jars on OSGi by using Atomos, then it would be nice to mothball these OSGi bundles.

Of course if it turns out that it really isn't doable, I'll try to find some way to fix them.

[Angular-Angel]

If you want to try messing around with things yourself, here's the project where I use your modules.

[Angular-Angel]

Make sure you download that specific branch, if you do want to mess with it.

[Angular-Angel]

Anyway, I've been looking at Atomos, and I suspect it's going to take me at least a few days to figure out how to use it, my apologies. :/

[Angular-Angel]

osgi-run also has it's own procedure for wrapping jars into bundles, but I'm not sure how it works.

[Angular-Angel]

Okay, having looked over Atomos, it looks like it doesn't have support for gradle (Specifically, a plugin, like it does for maven). So, using it with an application built via gradle will probably be a challenge? I'll keep poking at the thing and see if I can figure it out. :/

[io7m]

How are you starting your OSGi container? Using Atomos shouldn't require a plugin in any form... It's an API.

[Angular-Angel]

Using the osgi-run gradle plugin, at the moment. I was running a separate Karaf runtime and then loading all my modules from maven, earlier. I can try writing my own application that runs a container with Atomos, I guess? Not sure how to approach that, but I guess it might be as simple as 'main() { new Atomos().run();}'. :/

[io7m]

Ah, I see.

In the general case, it is pretty easy to start up an OSGi container in a plain Java application. Here's some example code taken from an old article I wrote on logging in Apache Felix:

https://github.com/io7m/osgilog2/blob/master/main/src/main/java/com/io7m/osgilog2/main/Main.java#L151

It uses the standard org.osgi.framework.launch.FrameworkFactory API to create an OSGi container, and installs a set of bundles into it manually. You can see on line 178 that I pass in various things to the framework (the subject of the article was how to inject a logging service doing this). This is where you'd pass in the Atomos instance as per their documentation.

[Angular-Angel]

Okay, I'll see about trying that out, thank you!

[Angular-Angel]

Okay, I got my OSGI runtime working. Now I need to see about wrapping non OSGI jars with atomos, I think? :/

[io7m]

To be clear, you shouldn't need to touch any existing jar files. The only condition is that those jar files be usable as JPMS modules. That's true of most jar files, these days.

[RefuX]

@io7m I just wanted to let you know I took your advice and tried LWJGL with Felix-Atmos. I have only tested the most basic possible example with a glfwCreateWindow call and it works!

For my test, I followed the Felix-Atmos guide and created a bundle directory with my libraries in it:

jline-3.13.2.jar
kotlin-stdlib-1.9.10.jar
kotlin-stdlib-common-1.9.10.jar
lwjgl-3.3.3-natives-macos-arm64.jar
lwjgl-3.3.3.jar
lwjgl-glfw-3.3.3-natives-macos-arm64.jar
lwjgl-glfw-3.3.3.jar
org.apache.felix.atomos-1.0.0.jar
org.apache.felix.gogo.command-1.1.2.jar
org.apache.felix.gogo.jline-1.1.8.jar
org.apache.felix.gogo.runtime-1.1.4.jar
org.eclipse.osgi-3.16.100.jar
osgi.core-8.0.0.jar
see-if-i-can-call-lwjgl.jar

The run command (forcing use of JPMS): java -XstartOnFirstThread --add-modules=ALL-MODULE-PATH -p bundles -m org.apache.felix.atomos (-XstartOnFirstThread is a macOS requirement for calling glfwCreateWindow and not needed for Atmos)

My see-if-i-can-call-lwjgl.jar bundle starts and the glfw window opens.

[io7m]

Nice, thanks!

@Spasi I feel like we might be at the point where we can archive this. Now that Atomos exists, there doesn't seem to be any good reason to keep maintaining separate bundles.

[Spasi]

@io7m That's great, will do.