The order in which files inside of a given directory are listed is not guaranteed in any way.
This causes tests to work on my machine but fail on out GitHub Actions CI/CD pipeline.
The SongodaYamlConfig might create a backup config file when upgrading a
configuration into a newer version.
This file would not get deleted in the old implementation
MockBukkit is not able to mock all of Bukkit's API
and broke with a change in PaperMC causing all our
current tests to fail. It is also version dependant.
But with Mockito you have to do everything manually right now.
No helping functionality (like creating a new mock player which automatically
will be returned in `Bukkit#getOnlinePlayers()`)
I took this opportunity to learn a bit about Mocking in Bukkit
and decided on Mockito.
It looks like we could easily write our own MockBukkit
alternative in the future.
I am not really happy how `Mockito#verify` works tho.
I find it annoying not to be able to directly assert
on the calls made to a method.
You have to create an InOrder instance first for the
mock and in the end verify with `Mockito#times(0)`/`Mockito#never()`
and `Mockito#any()` for each argument a method takes, to assert a total of n calls.
The method needs a `RandomSource` instead of a normal Java `Random`.
The method reference has been updated but updating
its usage has been forgotten.
Sadly I do not really know where to properly
get an `RandomSource` instance without instanciating it myself.
The field does not exist on Spigot (located in another class?).
But `#getEntities()` does exactly what we need and Paper-Spigot still has it.
SD-9374
SD-9377
SD-9392
SD-9401
This is intended to standardize how we do these request in the core.
It doesn't do much but it will sufice for now to be used
in the new localization system.
This also moves all the dependency declarations of the NMS modules
from the Core-Module to its own NMS-Module.
This module might get merged with the NMS-API module in the future.
This probably needs some additonal work but my idea
is that every NMS module has only one entry point.
This hopefully allows for as much freedom in version-specific
implementations as possible and allows for easily loading them via Reflections.
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.
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
