-
Notifications
You must be signed in to change notification settings - Fork 5
RFC: Does anyone still care about these bundles? #13
Comments
I'm trying to use them right now, they seem like they should be very helpful for me. |
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 |
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? :/ |
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. |
If you want to try messing around with things yourself, here's the project where I use your modules. |
Make sure you download that specific branch, if you do want to mess with it. |
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. :/ |
osgi-run also has it's own procedure for wrapping jars into bundles, but I'm not sure how it works. |
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. :/ |
How are you starting your OSGi container? Using Atomos shouldn't require a plugin in any form... It's an API. |
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();}'. :/ |
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: It uses the standard |
Okay, I'll see about trying that out, thank you! |
Okay, I got my OSGI runtime working. Now I need to see about wrapping non OSGI jars with atomos, I think? :/ |
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. |
@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 For my test, I followed the Felix-Atmos guide and created a bundle directory with my libraries in it:
The run command (forcing use of JPMS): My |
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. |
@io7m That's great, will do. |
I'm considering dropping support for these bundles, partly due to this bug:
#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.
The text was updated successfully, but these errors were encountered: