Pitest was unable to run because it could not find a couple of NMS classes and some other stuff.
We are excluding the `SongodaCoreConstantsTest` because it apparently
sees the Skip-Exception we are throwing as a failed test instead of a skipped one.
Causing it to abort its whole operation – Probably just a bug in Pitest
I also added the groupId to the two maven/test plugins as they were missing.
I wondered a couple of times why InjtelliJ cannot detect them while `mvn` runs as expected.
Looks like I never realised that missing - Now it is like it should have been
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.
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.
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.
