With Minecraft becoming more data driven and registry based, we are unable to tap into this large part of the api due to us having improper ways to handle modifying these registries safely. Most adding into registries must be done at the very start of the server, where before they are frozen, preventing any type of modification after that point. Our current plugin system is built on the entire concept that there must be a server object being passed around, and because at that point there is no Minecraft server this system will not work at all.
We need to be able to introduce a way for plugins to provide a class that is called in this spot, where we can give access to certain registry based apis.
We could simply scan all jars for a special field in their ymls, where we avoid having to touch really anything. This is a sort of hacky temporary solution at least.
This is a big feat but would truly bring so much more into the whole paper ecosystem in the future. What if we separated and basically made our own paper plugins? Note: We would still use JavaPlugin and such.
This would also allow us to also let hangar have a section of plugins that are made specifically for paper, perhaps where plugins could be marked with a special tag or something.
This would also allow us to add the life cycle stuff or just make paper plugins not reload at all.
A lot of feedback is appreciated here.
My initial idea was to make each jar a plug-in "provider". Providers can create a Plugin instance and have a configuration. Which type they are is identified if they have a paper-plugin.yml or plugin.yml. Providers would then be stored when the server is started, this has no class loading logic and instead only loads the configuration for later reference.
These providers would be stored into their corresponding loaders, where they will be responsible for moving providers around when needed. This part is needed because we néed to be able to move around plugin providers and merge them in certain places inorder to make sure they work with things like dependencies. The loaders would refer these providers to managers, where for example one would handle creating the JavaPlugin instances and merging them together. There would be a pre initializer manager too, I haven't worked out the exact implemention for that.
Feedback 1: Should these "pre initalize" classes be separate or part of the paper plugin? As in, should they both share the same classloader or be treated independently?
Feedback 2: Should we try to reuse as much of the spigot plugin code as possible? Or just, redo it here.
Feedback 3: Should we completely redo JavaPlugin with this? I'm against this myself, as the goal of this is to simplt redo the loading process but in the end have all active plugins in the server be JavaPlugins.
- We need to make sure here that paper / spigot plugins load in exactly the same way. We cannot change where the plugins are loaded without breaking dependencies or what not, so spigot plugins and paper plugins would need to be merged at some point in the loading process.
- Keeping compatibility with spigot plugin api.
It should be noted that this isn't meant to move away from spigot plugins. However, when paper hard forks it might help people to know if certain plugins are made specifically for spigot/paper if they download them blindly. Spigot plugins would be supported, but paper plugins would give more functionality possibly in the future. Also, if paper were to ever burn up people would be stuck with having to support these paper plugins too. Are we sure it's best to brand plugins like this?