SPONGE-12: Command API discussion

Please help us discuss the implementation of a command API.

The relevant issue is: http://issues.spongepowered.org/youtrack/rest/agile/Sponge-1/sprint/Inspired+Wallaroo#taskid=SPONGE-12

  • You will have to register on the issue tracker separately.
  • Please scroll down to SPONGE-12.


Just comment on the changes introduced here:


If you have a forums account (and you’re not logging in with Google), try logging in with those credentials first. You might just find it works.


Unfortunately does not work with forums credentials.

It does work with forum credentials.

Oh I tried again and it now works, my bad.

What about making one class for one command? The methods in class would be then sub-commands (marked with annotations).

I think, that is pretty nice code design.

You would the have for example HomeCommand class and that class will hold logic for all subcommands as:

  • /home
  • /home set

The class would be then registered:

Sponge.getCommandManager().registerCommand(new HomeCommand());

What do you think guys?

1 Like

I disagree. I strongly prefer having commands be explicitly registered instead; then subcommands could be handled in a much neater, and infinitely nestable, fashion:

    Command.of("get", Commands::get),
        Command.of("get", Commands::helpGet)

Tiny commands could also be specified inline with this syntax.

Yes, this example uses Java 8 features (why are we still using Java 6 which went EOL over 1.5 years ago?), but it could be reproduced easily in Java 6 with a bit of boilerplate. Also, the interface-side code would remain the same; only the plugin would need to be built with Java 8 for the pretty version.

Aside from that, see my reply to the issue for some other reasons on why I believe that to be preferable over the annotation way.

1 Like

Because Apple and Mojang.

1 Like

Looks very available to me.

Just because the Mojang code lives in the past doesn’t mean Sponge can’t require something released within the last decade.

This is really interesting. I like this idea. We could also make a command interface, just like how BukkitRunnable used to function…

    new Command() {

        public String getLabel() {
            return "command-name";

        public void runCommand() {
            // runs command.

        // etc

…not sure @Maulss actually read the tickets.

We are not going to have annotation support in the interfaces. There is no need for them to be part of the interfaces for you to be able to use annotations.

If you want annotations, you can create a class to generate CommandCallable classes to dump into a Dispatcher.

It was just an example, or an idea more like.

What I was getting at completely removes the use of annotations in terms of making commands.

No, it actually does not. There’s no reason why you can’t generate Command instances on the fly for each annotated command.

What about Google auth?

OK everyone, I decided to just implement the command interfaces:

Please make comments, suggestions, etc.


Yaa :smiley:
Time to close my PR. Not even sad about it xD.

EDIT: nvm you was faster than me XD.

In an old fork of my Bukkit plugin, I made a command system which had some nice features.

It did automatic parsing for sub-commands and some basic parameter types. It also did auto-completion for sub-commands and for parameters expecting player names or world names.

I’m not saying it’s a perfect design or implementation, but you may be able to get some inspiration from it.

Command API:

Example usage:

1 Like

I really support the Intake design. I was designing my own system to be very similar, but Intake is pretty much what Id like to see it look like anyways.

1 Like

I would love to see intake in sponge: Less wrewriting for my plugins ;D

I think a more important question is how this works with what Mojang is doing. Both Mojang comamnds and the command block syntax. You need something in your command API for that.