Bindings

All bindings for RPF basically achieve the same thing. They ensure certain components of the API you're developing with are automatically registered, and it will provide implementations for things that need custom implementations.

Maven/Gradle

When using a binding, set the scope to compile, and don't include the core. On top of that, you'll also need to provide your api's repo and dependency. For example, here's what a bukkit build.gradle would look like:

...
repositories {
    maven {
        url = 'https://repo.piggypiglet.me/repository/maven-releases/'
    }
    maven {
        url = 'https://hub.spigotmc.org/nexus/content/repositories/snapshots/'
    }
}

dependencies {
    compile 'me.piggypiglet:framework-bukkit:+'
    compileOnly 'org.bukkit:bukkit:1.14.4-R0.1-SNAPSHOT'
}

shadowJar {
    relocate 'me.piggypiglet.framework', '%package%.framework'
}
...

Users

User implementations have a sendMessage, and sometimes the specific implementation will provide a method to get the original user object, however, this isn't guaranteed, as there may be no original. You can expect the sendMessage to do things for you that'd normally have to be done manually, for example, in minecraft implementations, legacy colour codes will automatically be converted.

Files/Configs

If your API provides it's own config/file wrappers, you can expect the binding to have another wrapper for that. For example, the Bukkit binding provides a FileConfiguration implementation for Bukkit's FileConfiguration.

Commands

Commands are already automatically registered in vanilla RPF, but when using a binding, you can rest safe knowing that any extra configuration these may need for the specific api you're using will be done for you. For example, in velocity/sponge, registering the command in the command manager, and for bukkit, adding it to the commandmap.

Events

Any events/listeners that you register in your app will automatically be registered by your binding.

Task

If the api you're using has it's own task manager/scheduler, the binding will provide an implementation for it to wrap it into the Task abstract class.

Loggers

When using a binding, there'll usually be two ways to retrieve a logger. If the api you're using doesn't officially support custom named loggers, you'll be able to get a logger instance via @Inject private Logger logger; (e.g. Bukkit). Otherwise, get a logger like normal, with LoggerFactory#getLogger.

Other

To reiterate, anything that'd normally have to be manually registered, should be registered for you by the binding (excluding your own personal interfaces, unless you create registerables for them).