Now since Spigot 1.17, there is some level of support when using the mojang class names, methods and fields.
These names are unlikely to change so plugins using them should not have to worry too much about updating every new nms revision. However, because Spigot no longer provides deobfuscated field names and method names at runtime AND mojang uses different obfuscated names each minor version, plugin developers have to reobfuscate their plugin for each nms version (post 1.17) even though their nms-related source code does not change. (for example: https://github.com/Jannyboy11/InvSee-plus-plus/tree/master/Spigot_Impl_1_17_R1 and https://github.com/Jannyboy11/InvSee-plus-plus/tree/master/Spigot_Impl_1_17_1_R1)
I suggest that ScalaLoader provides a way for ScalaPlugins to be compiled using a stable naming scheme (one of which could be Mojang's naming scheme) and then the classloader obfuscates the plugin at class-load time, to make the plugin compatible with the nms names the server is using at runtime.
There is a legal gray area here because the mojang mappings may only be used for "development purposes", but it should be fine as long as the system is agnostic from these specific names and other naming schemes could be used as well. A developer could then choose the use the mojang mappings when developing the plugin, and transform the plugin to a different (stable) naming scheme (e.g. mcp/srg, yarn, mc-dev, parchment) before distribution.
Jannyboy11
commented
4 months ago
Now since Spigot 1.17, there is some level of support when using the mojang class names, methods and fields. These names are unlikely to change so plugins using them should not have to worry too much about updating every new nms revision. However, because Spigot no longer provides deobfuscated field names and method names at runtime AND mojang uses different obfuscated names each minor version, plugin developers have to reobfuscate their plugin for each nms version (post 1.17) even though their nms-related source code does not change. (for example: https://github.com/Jannyboy11/InvSee-plus-plus/tree/master/Spigot_Impl_1_17_R1 and https://github.com/Jannyboy11/InvSee-plus-plus/tree/master/Spigot_Impl_1_17_1_R1)
I suggest that ScalaLoader provides a way for ScalaPlugins to be compiled using a stable naming scheme (one of which could be Mojang's naming scheme) and then the classloader obfuscates the plugin at class-load time, to make the plugin compatible with the nms names the server is using at runtime. There is a legal gray area here because the mojang mappings may only be used for "development purposes", but it should be fine as long as the system is agnostic from these specific names and other naming schemes could be used as well. A developer could then choose the use the mojang mappings when developing the plugin, and transform the plugin to a different (stable) naming scheme (e.g. mcp/srg, yarn, mc-dev, parchment) before distribution.