Currently Bungee's plugin manager class is used to load and handle any Bungee plugin that gets loaded by Snap. This means that there is a clear division between Velocity and BungeeCord plugins without them knowing about each other via the plugin manager's API.
Ideally the plugins would be loaded directly by velocity's plugin manager. This would probably require some bytecode rewriting/javassist usage though to make methods like onLoad and onEnable work as well as make it compatible with what Velocity expects from plugin objects.
Another benefit of this would be to reduce the performance/memory impact that running two plugin managers could have as well as open up the possibility of registering events listeners directly with Velocity's event system instead of manually forwarding events.
Solutions should only dynamically modify classes of the plugins on load and not Velocity classes. (If necessary API should be PRd)
Currently Bungee's plugin manager class is used to load and handle any Bungee plugin that gets loaded by Snap. This means that there is a clear division between Velocity and BungeeCord plugins without them knowing about each other via the plugin manager's API.
Ideally the plugins would be loaded directly by velocity's plugin manager. This would probably require some bytecode rewriting/javassist usage though to make methods like
onLoadandonEnablework as well as make it compatible with what Velocity expects from plugin objects.Another benefit of this would be to reduce the performance/memory impact that running two plugin managers could have as well as open up the possibility of registering events listeners directly with Velocity's event system instead of manually forwarding events.
Solutions should only dynamically modify classes of the plugins on load and not Velocity classes. (If necessary API should be PRd)