+ small refactoring – Putting the *expesive* method calls outside the string into variables
to easier see them, when trying to understand the code and the need
for its own thread for just printing some messages to the console.
This prevents fragmentation of the idividual lines. `#getIP()` can take a couple of seconds
and because it is executed outside of the main-thread, other message can be printed bevore
the IP address and UUID are ready to be printed.
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.
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 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
I'm currently reverting some breaking changes so I can introduce them later and some imports broke in future commits. This fixes them
One of the related commits (may not exist anymore): 3d328df7ad
This commit removes the duplicate error message run when the plugin crashes and turns it into one method 'crash'. This method takes in a throwable, which will be printed once the error message is logged.
