# Changes:
- Added /ban <player> <reason> [duration] command. Bans a user on the server for the specified reason and duration (in minutes). If no duration is specified, the default is 5 minutes.
- Added /kick <player> <reason> command. Kicks a player on the server for the specified reason.
- Added /whisper <player> <message> command. Send a private message to a player on the server.
# Changes:
- Changed Configuration#getList(String, Class) to Configuration#getCollection(String, Class)
- Renamed GenericConfiguration -> GenericConfig
- Implemented semantics for GenericConfig#getCollection and GenericConfig#getStringList
- Adjusted return value of ContextProvider#fromString to return Optional<T> instead of @Nullable T
- Adjusted classes which used previous API methods to use the newly updated ones.
# Changes:
- Removed specific TOML wrapper in favor of GenericConfiguration.
- Added ConfigType enum to define configuration formats, parsers, and writers for TOML and JSON.
- Created FileUtils class containing useful file and directory creation methods
- Added @ApiStatus.Internal to both the BukkitDelegate class and Completions annotation to specify that they should not be used externally.
* Port to ClassGraph
* Migrate to Minecrell plugin-yml
This allows us to load libraries at runtime instead of using shading & creating massive JAR files.
* Fix constructor modifiers of cake command
* Fix improper usage of CommandMap
* Return primitives in configuration interface where possible
This should save some unnecessary performance and memory overhead caused by the storage of object wrappers of the primitive types and the unboxing of those object wrappers into the wrapped primitive types when we try to do some primitive-exclusive operation.
I doubt that we'll be using the additional sugar methods that these wrappers provide most of the time, and if we need to we can just box the returned primitives.
* Mark returned lists in Configuration interface as Unmodifiable
I can't think of a use-case where we would want to modify the returned list from the Configuration interface we're accessing; however in case those situations do in-fact exist, I've made the decision to mark the return values of those methods as Unmodifiable so that there are no confusions in the future when the returned list throws an UnsupportedOperationException
* Provide class parameter in Configuration#getList
Otherwise, it's impossible to actually check if the on-disk configuration values are actually of the same type as/a subclass of what the plugin is expecting in the implementation.
* State that Configuration#getList will return an empty list if it fails
I don't think it would go particularly well if we were to return a list of Objects when we have a parameterized method. Additionally, how would components of the plugin respond to being given a list of Objects instead of whatever type they were expecting? This should be a better fail-safe solution compared to what we were previously going to do.
* Return an optional in Configuration#get if something went wrong
* Add class parameter to Configuration#get
* Update JavaDoc of Configuration#getList to reflect new parameter
* Remove final modifier from parameter
* Add class parameter to Configuration#getOrDefault
* Fix misspelled JavaDoc tag
* Partially implement a wrapper over FileConfiguration that implements our Configuration
* Fix codestyle violation
* Add copyright header & change package
* Add code for WrappedBukkitConfiguration#getList and WrappedBukkitConfiguration#get
