SignEdit for Bukkit

Fixed

• /sign ui compatibility with Bukkit 1.18

Under the Hood

• Now that Bukkit 1.18 has introduced a stable API for opening the sign editor (org.bukkit.entity.Player#openSign(org.bukkit.block.Sign)), we reap the following benefits:
  • No more dependency on CraftBukkit – /sign ui previously tried various reflection workarounds to invoke the sign editor and always assumed that the server was running CraftBukkit without too many changes. SignEdit for Bukkit >= 1.12.7, < 1.13.4 settled on a minimally intrusive unstable API call that worked for CraftBukkit 1.8 through CraftBukkit 1.17.1, but CraftBukkit stopped mapping method names starting in CraftBukkit 1.18, which broke /sign ui.
  • /sign ui won't break in future versions of Bukkit – As SignEdit for Bukkit = 1.13.5 now prefers to use the stable Bukkit API, /sign ui will keep working on future major versions of Bukkit.
• For improved compatibility, the old reflection-based sign editor open call―now named net.deltik.mc.signedit.interactions.UiSignEditInteraction.openSignEditorWithReflection()―will try to find the unstable API ("NMS") EntityHuman method to open the sign editor based on the TileEntitySign passed into that method rather than by the name EntityHuman.openSign(). CraftBukkit no longer maps the NMS method names. This fix is moot for Bukkit 1.18 and newer, but it may be less likely to break other CraftBukkit variants.
• The plugin will now build on Java 17. CI will continue to build on Java 1.8 for compatibility with Bukkit 1.13 servers.
• Gradle will now use Java 1.8 to build the plugin. Redistributors or future versions of this plugin intending to build on newer versions of Java can change the Java toolchain language version in the build.gradle file to override this behavior.
• CI now uses a newer Java 17 image for build-time dependencies. The resulting build artifact will remain compatible with Java 1.8.