Edit: Only a point to say, didn’t realize the post was locked, first time using this forum >.<
I personally use a plugin called “PluginReloader” on my spigot test server, This works with no issue. its not the same exact as unload, you target a designated plugin. I have had NO issues with dependencies of other plugins. Normally .reload breaks essentials, it didn’t break essentials when I tried that as an experiment. Personally I would love such a plugin for my testing serv because of that reason. I find it a perfect development tool to use. I mean worst case scenario ill figure it out for myself so I have it, I only use it on a development server anyways.
Some people pointed out most server owners prefer only config reload and this is true. The only reason to use a plugin reloader is if your activity developing the plugin and don’t like restarting the server every time. But being able to load and unload a plugin is useful if you need to disable a plugin quickly but don’t want to interrupt player activity. (maybe the plugins derping out) as some popular ones rarley but have happened to do so.
I do need to point out before anyone talks about breaking plugins, it does detect if the plugin wont load properly and informs the person using the command that the plugin can only be reloaded by restarting the server
I have noticed though if the plugin yml name and the actual plugin jar name doesnt match up it doesnt work, tells you the only way to reload it is to restart the server
Quite simply, it’s impossible to guarantee that a reload will always work as intended. The Sponge leads decided that including something which mostly works as intended just isn’t good design.
The problem is “static” objects. Static objects stick around after a plugin has been reloaded, they only disappear when a Java application is completely terminated. There is no easy way to reload a plugin with Sponge guaranteeing that no residue like this is left over from before. If a reload was added, it would allow for errors, crashes, and potentially even exploits which is not something the team leads want to have.
Other Java based systems like Android get around this by doing exactly what we do - completely stopping the application and the starting. The difference is that Minecraft has much more heft on startup than those applications do. As such, you’ll only see about a second of reload time, compared to upwards of a minute for Minecraft.
Sponge isn’t Spigot. The API is different to fundamentally different in some places. Having the option to reload plugins completely would cause serious issues, as the plugin registers itself and various things in the startup phase of the server. While reloaded you just couldn’t register these things.
Same for plugin dependencies: What happens if you reload an economy plugin? The plugins depending on said econ plugin won’t be happy about this
This is possible in Sponge but up to the Plugin dev.
All I can add to this discussion is that plugin reloading will NEVER be added to the API. The game is very stageful and plugins attempting to reload other plugins by throwing various state events will see a lot of issues from both ends. There’s many cases where we simply cannot allow plugin reloading, namely the GameRegistry and anything to do with DataSerializables and their respective DataBuilders. I enforced in the implementation that all registration of DataBuilders need to be done before the server starts loading worlds BECAUSE of deserialization requirements. Plugins attempting to re-register their own builders would result in exceptions being thrown in this case.
Furthermore, as was pointed out earlier, “development” tools should be left when in the development environment where crashes and exceptions are to be expected, because you’re in development. In production, the most you should expect is plugins having built in functionality to reload their configuration options if they’re needed. Short of that is asking plugin devs to add useless functionality for the production environment when there shouldn’t be.
Lastly, when you consider “reloading”, try telling that to forge mods and see how well that goes.
Idk about how the standard @Inject config works but all my plugins, changes to config files are dynamic, so reload is pretty useless. I only have one plugin that has it’s own reload command for stopping and starting scheduled tasks but that’s about it. I think reloading anything in Sponge should be up to the plugin developer.
When I create a Sponge plugin, I use IntelliJ to start the server. So if I do any changes I can reload the modified classes directly without having to restart the whole server.
I do want to thank the people that pointed out the issues with things such as
As for
adding /reload to the sponge api was never implied in this set thread nor by me what so ever. It was implied to be as a plugin that you can designate the plugin in which you want to reload. NOT ALL PLUGINS at one time.
For example, /plugin [reload/unload/load] [pluginName]
again thank you to the ones that pointed out the registering issue and such
Now that I think of it, yea true the plugin registers on the GameInitializationEvent, which only occurs when a server is started. >.<
FYI I may change the architecture in future iterations: instead of a general re-loader for any plugin, an approach of making a library for a particular single given Plugin which can hot reload it’s own controlled “pluglets” (?) is probably a better take on this. And that should be possible without forking/hacking Sponge. Watch my repo to see if I make progress in that direction.
@vorburger I’ve looked at this and considered it may be potentially useful, provided you re-submit the PR as purely a mixin plugin that by default is disabled (mixin plugins are much like the Bungeecord mixin plugin where the alternative code is not directly applied at runtime). Although I can’t verify whether it will be stable for some corner cases where class generation takes place, but I can see the uses. Out of curiosity, why isn’t hot swapping in IDE sufficient?
@gabizou tx for your reply >1+ yr ago, and sorry for (very late follow-up …
So hot swapping from an IDE has significant limitations - it only really works great for changing a few lines in existing class, but you cannot really “dynamically develop” with it - say start your Minecraft server in the morning, then create a new mod, add new classes in, re-factor it, keep coding a mod all day long - all without ever restarting the server.
FYI I’ve meanwhile stopped working further on my GitHub - vorburger/HoTea: Plug-In framework with HOT Class reloading for dynamic script-like Java, as I’ve in a parallel life (day job work) eventually learnt more about OSGi, which is a much better foundation for this kind of thing - it has already solved the typical kind of problems one runs into with something like this like, dependencies and versioning and what not, and has a rich existing ecosystem around it.
