Purpur-Spigot and plain Spigot do not end with `.0`. Not sure if Paper does or Spigot 1.19.1 does?
I just added the plain `1.19` check.
This is not an issue in the Core v3 branch as the check is more stable there.
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
Moved code into private methods to make the Location#at call more readable
and to reduce duplicate code.
`PlotSquared.get()` is marked as `@NotNull` and is never null
if `PlotSquaredProtection#isEnabled` returns true.
That's why I removed the `null` check on the *API* with a check if PlotSquared is enabled.
I replaced the usage of Java StreamAPI with a simple for loop for better potential performance.
The loop is so simple and we don't know the plugins that might be using this class,
thus greater performance for a small loss on readability is probably worth it
+ Removed some unused imports
This allows to chain the default value instead of using the setter or constructor.
Long keys/values can be put into individual lines which improves readability.
In the future, we might want to have a Builder class that contains all thise #with methods
The build pipeline already runs the tests. I think it makes sense to run SonarCloud's static
code analysis when the project can be compiled without errors.
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.
