Migrating from 0.4.0 to 0.5.0

Note - Still WIP

Change pom/gradle file for new module name

0.5.0 introduced a module style project, where bukkit specific stuff is now in its own artifact.

You must change acf-core to acf-bukkit OR acf-paper (if you will require paper for your plugin) in your pom.xml or build.gradle file. Also ensure <scope>compile</scope> is set

Example POM:

    <dependencies>
        <dependency>
            <groupId>com.destroystokyo.paper</groupId>
            <artifactId>paper-api</artifactId>
            <version>1.11.2-R0.1-SNAPSHOT</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>co.aikar</groupId>
            <artifactId>acf-paper</artifactId>
            <version>0.5.0-SNAPSHOT</version>
            <scope>compile</scope>
        </dependency>
    </dependencies>

Update Manager creation

First change your Manager type to be exactly what it CommandManager -> BukkitCommandManager or PaperCommandManager

Then instead of ACF.createManager(plugin) do commandManager = new BukkitCommandManager(plugin);

Add , BukkitCommandExecutionContext to method based context resolvers

If you have a method like

public ContextResolver<MyType> getResolver() {
   return c -> { };
} 

Then you need to adjust the return signature to

public ContextResolver<MyType, BukkitCommandExecutionContext> getResolver() {
   return c -> { };
} 

Add <BukkitCommandExecutionContext> to method based completion handlers

If you have a method like

public CommandCompletions.CommandCompletionHandler getCompletionHandler() {
   return (sender, config, input, c) -> { };
} 

Then you need to adjust the return signature to

public CommandCompletions.CommandCompletionHandler<BukkitCommandCompletionContext> getCompletionHandler() {
   return c -> { };
} 

See next section for more information on the parameter signature change

Change in signature of CommandCompletion Handlers

Previously a completion handler looked like this:

 registerCompletion("players", (sender, config, input, c) -> {
    // ...
 });

The first 3 were legacy parameters before we added the Context system that matches how Context Resolvers work.

The Context object is better so that we are able to continue to expand the API without breaking your existing code.

When we added context, we left the original 3 to keep the changes small to introduce the context (c) parameter. But now we are dropping the original 3 as all of them are accessible inside of the Context parameter (and .getConfig has more power in Context than the plain config string, by supporting more than 1 config)

Now, we have dropped the first 3 parameters so that the Completion Handlers are implemented the same way Context Resolvers are. It should now look like this:

registerCompletion("players", c -> {
    CommandSender sender = c.getSender();
    // ...
});

You may see a full diff of the changes here with examples: https://github.com/aikar/commands/commit/15b149d55c555a080d50836f4999fe1ecaa481b7

Update local references to CommandCompletions

If you copied CommandCompletions to a local like so:

CommandCompletions commandCompletions = EmpirePlugin.commandManager.getCommandCompletions();

You will need to update it like so:

CommandCompletions<BukkitCommandCompletionContext> commandCompletions = EmpirePlugin.commandManager.getCommandCompletions();

Update local references to CommandContexts

If you copied CommandContexts to a local like so:

CommandContexts commandContexts = EmpirePlugin.commandManager.getCommandContexts();

You will need to regenerate the reference or update it like so:

CommandContexts<BukkitCommandExecutionContext> commandContexts = EmpirePlugin.commandManager.getCommandContexts();

Usage of @Override preCommand

Drop commandLabel (use .getExecCommandLabel()), add @PreCommand and remove @Override like so:

@PreCommand 
public boolean anything(CommandSender sender, String[] args) {

}

Same as before, return true to abort.

Usage of @Override help

Same as above, but use @UnknownHandler

@UnknownHandler
public void help(CommandSender sender, String[] args) {
}

Removal of BaseSubcommand

Simply change all use of inner classes extends BaseSubcommand to BaseCommand (same as parent)