@curscascis thank you (and the other Likes) for the love - appreciate it. More likes, anyone?
@d4rkfly3r tx for the (first, real) Q here. So yeah you’re spot on there, absolutely right - there’s no magic fairy dust, in this world… It’s all real work! So your mod/plugin’s code still has to correctly unregister and (re) register any “hooks” (commands, event handlers and the like) into its surrounding environment (in this case, Sponge), at the right time in the lifecycle. The way I have it for the moment (this COULD evolve later), as outlined in #7 on the projects README, an OSGi-based Minecraft Mod uses an OSGi Bundle Activator, instead of the Sponge @Plugin annotated class, to register its Minecraft Commands and Event Listeners. This keeps things clear and nicely separated, to start with. Now you can, of course, make a project have both a Sponge Plugin as well as an OSGi Activator (links to an example where I’m successfully doing this), and register the same commands and listeners in it; thus creating a JAR which is usable in both environments - both as OSGi bundle (during development, for fast iterative development) as well as a “normal” Sponge mod JAR (for distribution).
This could evolve in the future - e.g. there could be what’s called an OSGi Extender which would automatically detect the @Plugin annotated class and invoke it’s lifecycle methods correctly itself - that’s totally doable (and then there would be no need for an Activator; this is similar to what e.g. OSGi’s Blueprint implemented by Apache Aries, or the OSGi Declarative Services DS do).
Of course, if your respective code does not unregister stuff (e.g.
removeMapping for commands, and the like), then you can create havoc in Sponge and “it gets pretty made” (@codeHusky) , and it will not correctly reload, yeah. IMHO that’s just too bad - life is tough, and short - so just code well?
This also could theoretically evolve in the future, and it’s not impossible to imagine transparent auto-unregistration of stuff; FYI e.g. OSGi own service registry (which is something similar to Sponge’s
ServiceManager), is actually smart enough to unregister all services registered by a bundle when it unloads, without it having to do that explicitly. It would imaginable to build something like that into this. A minor problem one may run into with Sponge’s current API is the static Sponge Game stuff, which probably makes it a bit harder to intercept registrations to be able to automatically undo them; but there are ways to work around it.
Now for your specific example of
MinecraftForge.EVENT_BUS.register(), I wouldn’t actually know myself what the
unregister() equivalent of that API is - sorry. There should be one, and if there isn’t, one should be added (eventually). At least Sponge’s
EventManager do this right, and offer both
unregister type of API methods.
As for your Q re. “when it depends on another plugin/mods events to finish setup or something”, that entire area has been well threaded in OSGi. What you usually do it make something dependant on a service published by something else. Solutions such as DS then are smart enough to restart things in the correct order when others come and go.
@gravityfox may I in turn clarify? The OSGi in the plugin name is totally accurate, because that is what this project is - it’s a Sponge “plugin which embeds an OSGi Framework” (first line of the README). On your SOA rant, yeah… A few years ago, EVERYTHING had SOMETHING to do with “SOA”, and so OSGi too was labeled, as was even my aunt’s SOA enabled labrador puppy! And nowadays everything is a “Microservice” (even OSGi services)… Be that as it may, none of it changes the fact that an OSGi framework at the end of the day basically is just another little ClassLoader framework (and a reasonably well thought through one, IMHO). Not exactly sure where you’re going re. the “state agnostic lifecycle” - but I gathered you know more about Minecraft’s current internal implemenations than at least I do. All I can say to you is that I wanted to have a way to build Minecraft plugins “in such a way that you can remove and swap without having to halt the rest of the application”, and after earlier experimenting with some custom ClassLoader tricks of my own, found OSGi to be a good fit for this. I’m using this myself to write some plugins, and it works great for me. YMMV - I respect that.