Upstream has released updates that appear to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
Bukkit Changes:
6b3c598b PR-814: Add a method to send multiple equipment changes
181a984b Update Maven shade version to align with CraftBukkit
a5a36e32 Revert "Update Maven shade version to align with CraftBukkit"
7a8f4a42 Update Maven shade version to align with CraftBukkit
58327201 Add support for Java 20
CraftBukkit Changes:
b56426c7a PR-1142: Calculate explosion damage separately for each affected EntityComplexPart
fbe3410af PR-1140: Add a method to send multiple equipment changes
8434e3633 Add support for Java 20
c998a1d23 Increase outdated build delay
4a929b5d6 SPIGOT-7267: Fix EntityType#getTranslationKey() and add unit test
086d8dc8a SPIGOT-7268: CraftMetaPotion reads ShowParticles and ShowIcon properties incorrectly
8ba5e399e SPIGOT-7262: Improve visibility API
Spigot Changes:
a2190e30 Rebuild patches
There's some inconsistencies between the EntityChangeBlockEvent and the BlockDestroyEvent. The destroy event has always the right final type but the change block event has always air even for waterlogged blocks. This fix this behavior only for possible case to avoid a bigger patch.
Abstracts relative teleport flags and instead makes a generic TeleportFlag option. This has the benefit of being able to easily add new flags in the future.
This adds a new flag, which allows you to keep inventories open when teleporting players (vanilla behavior).
These are breaking changes to the teleport api, however, it's still marked as experimental so I find this a fair change.
A recent patch moved the internal unit tests to mokito, allowing
deep mocking to easily setup a mocked server instance.
While this change is useful, the server's Server#getItemFactory methods
is one of the hottest paths during unit testing, being called numerous
times by material tests.
As mokito mocks keep track of each invocation to allow for verifications
of invocations down the line, the server mock allocates a huge amount of
memory to keep track of all invocations, ultimately leading to an OOM
exception.
The previous solution solved this by increasing the tests memory to 2 GB,
however as of right now simply configuring the server mock as "stubOnly",
properly prevents the overflow of invocation records as none of the unit
test code relies on invocation verification.