Hi everyone,
I propose an ant task that builds OSGi bundles from the jME source. I downloaded jME yesterday and found converting the whole engine to an OSGi bundle to be very easy.
Up to now I only built a monolithic bundle containing all the functionality plus fragment bundles for the different target platforms, but I'm pretty straightforward that it would work with separate bundles for all jME modules.
Unfortunately I'm not very experienced with ant but I could put together the specs for the manifests that need to be generated.
OSGi is just perfect for anyone looking to write modular and extensible games. No cooking up your own plugin-system anymore. Just provide a bundle containing the interfaces to your game and rejoice as new functionality gets injected into your code.
I don't really understand what is the point of those OSGi bundles… I did some research and I couldn't really see they are supposed to help. Could you perhaps elaborate on how exactly would OSGi bundles could help jME game development?
No cooking up your own plugin-system anymore. Just provide a bundle containing the interfaces to your game and rejoice as new functionality gets injected into your code.
What's the problem of making an interface and then exposing it to your users to implement?
I can see the point, but not sure if it is reasonable, maybe milgner wants to be able to create customized JME Engine, like just having particles and scene parts or just physics?
@ches:
Originally I had hoped that having separate bundles for each of the jME components and deploying only those required for a particular project would be a nice side-effect. After playing around a bit I found that there's a lot of inter-dependencies between the different JARs of the distribution, leading to classpath-import-cycles which the OSGi container doesn't like.
@Momoko_Fan:
There are a couple of advantages of running your application inside an OSGi container. First and foremost is the possibility to install, update, reload or stop components of your app on the fly. Second is Inversion of Control, aka Dependency Injection: if you expose some interface and some component shows up in your environment which implements this interface, you get notified of this (meaning you don't have to search for services, they are handed to your app).
Also it is possible to have multiple versions of bundles installed. So if - just as an example - jME depends on JOrbis 0.0.15 but I'd like to user a newer version 0.0.17 (assuming it has undergone some API revision), the bundle can be installed multiple times: jME sees version 0.0.15, my code the newer one.
It's all about flexibility: you could offer some menu allowing to download new content. After retrieving the file, the new bundle gets installed, and all classes and functionality are available to you without having to restart the game.
There's also some other stuff built in, like security but those have (as far as i can see at this point) only little relevance to game development.
Since I started using OSGi technology in my business application projects about a year ago, I don't want to miss it for a minute.
As I mentioned, I already cooked up some bundle manifests for my personal use and if you're interested, I'd be happy to, with a little help, think up a build process to generate them automatically as an ant build target.
Cheers
Marcus
Also, OSGi bundles offer a clean way of exporting of classes. In java, every public class is visible, in OSGi some packages can be hidden, thus being internal.
But there is already an OSGi version of jME available 
The monklypse project offers an Eclipse plugin for jME. But of course, it has eclipse dependencies, so its not pure OSGi
I would also vote for an OSGi version of the jME and a syncronisation process between the monklypse and jME
First and foremost is the possibility to install, update, reload or stop components of your app on the fly.
On my research about OSGi bundles I heard this a few times but unforunately I never in my coding found a need for this kind of functionality. I don't think jME could benifit from it either as it doesn't really have components that are "active". The components that are used are used when you use them in your code.
Second is Inversion of Control, aka Dependency Injection: if you expose some interface and some component shows up in your environment which implements this interface, you get notified of this (meaning you don't have to search for services, they are handed to your app).
I suppose this can be useful for implementing Renderer, sound system, input, etc. but all solid implementations are already there. If you wanted to write a DirectX renderer for example, it would probably be big enough for it to be added as core rather than a plugin.
Also it is possible to have multiple versions of bundles installed. So if - just as an example - jME depends on JOrbis 0.0.15 but I'd like to user a newer version 0.0.17 (assuming it has undergone some API revision), the bundle can be installed multiple times: jME sees version 0.0.15, my code the newer one.
There were a few issues I guess where you would like to use LWJGL1 (for FengGUI) while jME2 uses LWJGL2. However LWJGL doesn't use OSGi bundles and due to the nature of how it works I don't think it's possible to interoperate separate versions. E.g if you try to use LWJGL1 separately while the rest used LWJGL2 it would complain about missing display so you can't really combine the two. Same goes for physics and input.
It's all about flexibility: you could offer some menu allowing to download new content. After retrieving the file, the new bundle gets installed, and all classes and functionality are available to you without having to restart the game.
This is an interesting feature and would be quite useful in games. However it would be useless for the engine because if there are API changes your code will break.
Since I started using OSGi technology in my business application projects about a year ago, I don't want to miss it for a minute.
As I mentioned, I already cooked up some bundle manifests for my personal use and if you're interested, I'd be happy to, with a little help, think up a build process to generate them automatically as an ant build target.
I think OSGi can be useful for certain applications and of course you are free to use it for your jME app, but forcing other jME users to have the SDK installed would mean more work new people have to do to get jME working. There was a discussion about implementing Maven for jME and I don't think it worked out well, if IDE supported these dependency management tools (like ant) without requiring installation and manual configuration then I am all for it.
I found this an interesting reading about OSGi use cases: http://solutionsfit.com/blog/2008/08/27/osgi-what-modularity-can-do-for-you-part-1/
OSGi isn't very restrictive, you can choose whatever container you wish (Knopflerfish, Felix, Equinox, etc.). Even it is possible to work without an OSGi container at all, because after all, OSGi bundles are still simple jars.
Hiding implementation details IS very important, if you want to keep you code manageable and sustainable. So, if we say, some classes are internal (so we can later exchange implementation details), without OSGi there is no chance to avoid that developers use such internal classes. What happens with developers using hidden interfaces? Their code breaks after an update, and they complain about those non-backward-compatible changes.
The OSGi overhead is extremly small.
This sounds like an addition that could potentially enhance jME's accessibility. Any particular reason why the discussion dropped?
erlend_sh said:
This sounds like an addition that could potentially enhance jME's accessibility. Any particular reason why the discussion dropped?
No, but i didnt follow the jME forums for a long time...
Hi!
I'm an OSGI user and have architected an enterprise-grade commercial product-platform that uses it for its base container so I guess I can say I'm a bonafide fan of it. I've also been thinking of incorporating it into the scala rewrite I did of the FlagRush tutorial application so that having pluggable vehicles, etc. is easy.
However…
I'm not convinced that integrating it with JME in a generic way is such a good idea.
Specifically, I think that JME is too low-level for useful plugability. It's a library, not a server. The kind of bundle-based load/unload mechanisms and services-finding that OSGI provides are really more valuable one level up. However, that next level up is really dependent on the kind of application you're building.
For example MMORPGs and RPG's have very different "plugability semantics" than FPS games which are in turn different than driving sims.
So, while it is possible to force an abstraction… and it's also possible to make fine-grained components of JME into bundles (nodes, lights, terrainBlocks, etc.) I don't think either strategy will add much other than a moderate degradation in performance and a more complex build process.
BUT…
I do think that it is interesting to consider one or more higher-level abstractions ON TOP of JME that would more naturally map to OSGI bundles and which really would give a significant productivity boost… but they would only be for a specific subdomain of graphic applications. (For example, at the granularity level of Avatars, sets, BVH animations, whole shader trees, complete AI's, etc.)
For what it's worth 
– Pixelcat
This is very valuable feedback Pixelcat, thank very much! If you know more specifically any project around here (check, 'projects', 'user showcase' and 'user code') that could benefit from OSGI, don't wait to speak up. If someone should ask you for help with this, do you think you would have some time for it? I do not know if there are good enough tutorials around that would cover the subject sufficiently.
Pixelcat said:Have you released this Scala rewrite to the public? Could be interesting to see how it compares, as the jME3 core developers are considering Scala for certain parts, such as scripting.
I've also been thinking of incorporating it into the scala rewrite I did of the FlagRush tutorial application so that having pluggable vehicles, etc. is easy.
If someone should ask you for help with this, do you think you would have some time for it?
Well, like everyone, I don't have enough time even for my own projects. However I've received so much valuable help from others that I'm of course happy to help in any way that someone finds useful.
Have you released this Scala rewrite to the public? Could be interesting to see how it compares, as the jME3 core developers are considering Scala for certain parts, such as scripting.
My intention is to make it available in a week or so. I've only held off because a friend who is a scala maven is reviewing it for me (I did it as an exercise in learning Scala as well as JME :D) and i'd like to find some (mythical) time to add better comments and some brief tutorial text.
...well and I got sidetracked by puzzling my way thru a first try at skeleton/skin animation while adding a humanoid avatar as a second player vehicle. (Has anyone else discovered that the 0.3e Hottjb importer/converter for Blender creates *-jme.xml files that require the latest .svn build of the JME source and won't work with the latest prebuilt distro?)
Maybe I should set that aside for a while and just add a car or something simpler than a full-blown human AV and a sample use of OSGI to support drop-in addition of vehicles and get things cleaned up to share with folks.
Cheers,
-- Pixelcat