The original code did not allow addons to talk to each other in any way.
After trying loads of things with class path I studied the bukkit code
and saw that they override the findClass method in URLClassLoader. This
enables addons to find classes in other addons. All that was then needed
was a map in the AddonsManager of classes that this manager knows about
and a getter and setter method for them. After all that (3 hours) it
works.
I'm working on addons and realized it would be a better approach to be
able to register the listener for a panel explicitly for each panel.
This is optional. Also, added the ability to open the panel immediately
for a player.
Used reflection to get the command map from the server instead of using
the NMS call.
Also, more importantly, this commit enables CompositeCommands to
auto-register their top-level command in the constructor. No need to
separately obtain the command manager object. Yes, easy API. :-)
Moved PremadeEvent to api/events
Made use of PremadeEvent for all existing events
Renamed TeamReason to Reason in TeamEvent
Made the addon events follow the used builder pattern
Renamed #loadAddons() to #enableAddons() in AddonsManager
Added #disableAddons() in AddonsManager
Commands now require a setup to define their permission, player/console
status, description and any parameters they have. This is also where any
subcommands are created if they exist.
Each command automatically has a help subcommand. This is used to
display help. This will also recursively go to any other sub commands
and get help from them.
Note that getUsage() now *only* shows the command and any sub commands.
It turns out that Bukkit requires this to start with a / because it
actually uses this in its own help system and the server will not start
if it is not in the right format. Therefore I split off parameters into
their own string. This also enables them to be translatable.
Everything should work at this point. It's just waiting on the locale
system to work to display the strings in the locale files.
