Library NetworkUtilities - 6 Line Command System!

Hello There!
I've just finished the first public release of NetworkUtilities. It's a very lightweight, easy to use system for controlling all of your Bukkit plugins.
For example, to make a /feed command - simply:

1. Add the plugin to your server
2. Add it to the class path of your plugin
3. Add the following to your plugin:

Code:java

CommandManager manager = newCommandManager(this);
manager.registerCommands(this.getClass());
 
@Command(command = "feed")
public static void feed(Player player, List<String> args){
    player.setFoodLevel(20);
}

You'll have a new Command, without the need to add it your plugin.yml, or anything! It's that easy.

You can make block breaking OP only with just:

Code:java

getServer().getPluginManager().registerEvents
(new BlockBreakHandler
(new OPPermissionSet()), this);

Wiki: https://bitbucket.org/olivervscreeper/networkutilities/wiki/Example Plugin
Download: http://ci.nixium.com/job/NetworkUtilities/12/

Please let me know what you think, and any feedback. If you end up using it, please tell me how you get on.

 

olivervscreeper
That's neat, but I've seen a few similar ones, especially the command thing.

And the wiki seems to inaccessible. "You do not have access to the wiki. Use the links at the top to get back.".

 

There are lot's more features, shame you couldn't see the Wiki, that's the hub for it all. Take a look now - what do you think of it?

 

This is cool, like a faster version of the bukkit API?

 

Much Faster, slightly quicker at runtime in some aspects, but most importantly, your code will be sooo much smaller! You could make blockBreaking only for OP's with just one line of code.

 

I don't see how it's any faster than the Bukkit API if you're just calling the Bukkit API to begin with
Several other issues:

• If you're going to create dynamic commands (i.e commands that circumvent plugin.yml), you would want to get a hold of a Command object (either by extending Command in a new class or reflection or etc.) and register that. Using the command preprocess may be neat for now, but what if another plugin has the same command name as yours? Now you're just overriding their command no matter what. I believe you could do /<pluginName>:<commandName>, but don't quote me on that.
• Every time a player does a command and it is registered with your library, you loop through every method. While this shouldn't be much of a problem, it can hinder performance if you have a lot of methods within a single class. I suggest you use a Map<String, Method> and then cache the method instead.
• I'm not really sure what the use of the *Handler class is for. It looks like you're just filtering listeners out based on their priority by using the setCancelled() method...?
  edit for handler one: I looked at the source code a bit more; it kinda makes sense, but why do you listen on every level? If you want to go the extra mile, you could use hacky reflection to do it at runtime.
• The PermissionSet is a nice feature, but why store the UUID in it's string format?
• Why do you log that you're starting up? Bukkit already handles this. Plus, the compatibility line isn't necessary as you don't access any NMS or OBC classes.
• Agh; Singleton pattern. You need to wipe the variable named plugin along with command in onDisable so that the GC can grab it when the plugin is disabled.