-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
Description
Is your feature request related to a problem?
PaperMC is currently using the same plugin.yml like Spigot does.
This comes with all its pros and cons, especially when you make a plugin that should cater towards both and don't want to make separate jars for each.
A prime example would be the libraries option available.
While loading specific libraries - such as Kyori's Adventure library - makes sense on Spigot, is it sometimes wasted effort on a Paper Server due to it already offering it natively.
Other issues are that you may need to create stuff like interfaces to have convenience methods to f.e. send messages using Components on both Spigot and Paper which require extra stuff such as Class.forName checks to find out which server is actually used and if components are available.
Describe the solution you'd like.
Paper should offer a way to define separate options using a file like paper-plugin.yml
This basically would inherit what BungeeCord is already doing: Prioritize and use that file if present and otherwise fall back to the default plugin.yml file.
Such a file could yield several benefits:
- Define a separate main class to load, allowing you to split up paper-only stuff into a different section while keeping a single, universal jar.
- Have separate libraries defined to load on a Paper Server. Avoids loading of already provided libraries such as Kyori adventure.
- More enhanced/improved formats or options in general without risk of breaking existing
plugin.ymlformatting.
To add to the first point: Having a separate main class could then allow to use Paper-specific methods without the risk of having them used on a Spigot Server.
This could then allow Paper to provide convenience methods to f.e. check if a particular feature would be present, in case that is wanted.
Describe alternatives you've considered.
There are 2 alternatives for the libraries part I can think of: Shade it in or load it either way.
Both have their downsides (Increased jar size or loading of an already provided library)
For the other stuff did I already mention currently used methods such as Class.forName checks.
Other
No response