Depending on the environment the default system charset might not be UTF-8 beaking
messages files using non-english language etc.
I'm not sure but Spigot might even set it to ASCII? The tests succeed locally because I am
using Manjaro Linux which uses UTF-8 by default in the JVM. But testing a plugin and logging
the default charset returns ASCII instead (on the same machine).
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
