If you are reading a config dynamically instead of fully creating it
with all the entries beforehand, this method can be used
to easily access the *converted/casted* values.
A lot is happening in this release!
tl;dr: GitHub Actions runs tests, compiles the project, signs the jar files, deploys them to the Maven repo; Pushing a git tag issues a release instead of snapshot deployment; -SNAPSHOT is always added to the version otherwise; Core Version is now injected by maven instead of manually updating it in one of the classes
We now use GitHub Actions to run automated tests, compile the project, sign the resulting jar files, and always deploy a version to the Maven repo.
By default, a snapshot release is published but by creating a git tag, a release deploy can be triggered.
Additionally the Core version is not manually updated in one of the classes but injected after compiling it.
I think I found the most stable and easiest way to do this in maven,
although I'd have wished for it to be easier and maybe not after the class file has already been created.
Level.FINER is currently not logged anthough the Logger is set to ALL and isLoggable returns true for FINER.
There's an bug existing bug report at Spigot: https://hub.spigotmc.org/jira/browse/SPIGOT-7018
Escept for #getExtraConfigs which got renamed, the other methods are no longer required and have been removed.
Additionally the config methods defined by Bukkit's JavaPlugin class
have been overwritten with empty bodies.
This prevents the default behaviour trying to access stuff that's not there
or should not be considered a valid config to use.
This is required for unit tests (especially the `Bukkit#getServer != null` check).
But it seems faulty to even trat an unknown version like a normal one.
Because Spigot 1.18 still hasn't fixed a critical bug like PaperMC did, I recoded the current YAML Configuration classes and access SnakeYaml directly instead of using the Spigot wrapper.
This implementation approach also allows for adding node comments using the lib instead of some woodo string manipulation.
#41
// I might move this into my own library in the future, lets see :p
We probably want to take a look at what Spigot 1.8 comes with and if we are compatible or if we want to shade the lib into the Core instead.
Maybe we can have some kind of automatic legacy system that downloads an addional jar automatically when an unsupported Spigot version is detected... Lets see what time brings
