Closed DavidNery closed 2 years ago
I'd argue not using the plugin's name as the fallback is the plugin's issue, not PlugMan's one, but since I want PlugManX to work as good as possible, I will have a closer look at your code.
It is definitely a great idea though.
Thank you for time and contribution :)
Hey,
Sorry for the wait.
I tested it a few times with different setups, but it doesn't seem to work.
Throws an exception everytime it tries to access the PluginClassLoader class
Which line?
Nevermind, just used the wrong setup.
Seems to work just fine, but the method is still not 100% reliable.
There can be some rare situations where neither the ClassLoader method nor the Fallback Prefix method will work.
A good example for this would be my plugin "ServerSystem".
If I didn't register the Fallback Prefix to "serversystem", PlugManX would not be able to find any commands.
I will test a few things with the ClassLoader approach.
After that I'll merge.
Thank you for your time and contribution :3
The problem
Some developers prefer to directly register their plugin commands using CommandMap#register directly, instead of registering it in
plugin.yml
and then callinggetCommand("<command>").setExecutor(<main>)
, which will register the commands correctly in the command list, but the current Plugman code will not find these plugins if the fallback (prefix) is not the plugin name.The solution
With this PR, I implement the use of PluginClassLoader, which is responsible for loading plugin classes into memory, including plugin commands. However, this object also saves the plugin it loaded. Thus, each JavaPlugin loaded on the server has its own PluginClassLoader, allowing to identify the plugin responsible for each command registered on the server.
Why not just use ClassLoader?
When you look at the code, you will see that I also kept checking for the fallback of the command. It's because during my testing, some plugins (like Vault) don't use PluginClassLoader to load their classes. So, using these two methods, we can find any plugin responsible for a specific command.