WorldEdit

WorldEdit

45M Downloads

Bundle Mojang mapped adapters as output jar

NotMyFault opened this issue ยท 6 comments

commented

WorldEdit Version

7.2.8-SNAPSHOT+5955-3ba0890

Platform Version

git-Paper-"3f17694"

Confirmations

  • I am using the most recent Minecraft release.
  • I am using a version of WorldEdit compatible with my Minecraft version.
  • I am using the latest or recommended version of my platform software.
  • I am NOT using a hybrid server, e.g. a server that combines Bukkit and Forge. Examples include Arclight, Mohist, and Cardboard.
  • I am NOT using a fork of WorldEdit, such as FastAsyncWorldEdit (FAWE) or AsyncWorldEdit (AWE)

Bug Description

Loading WorldEdit on a Mojang mapped jar, leads to it firing the message below.

[12:18:52] [Server thread/WARN]: 
**********************************************
** This WorldEdit version does not fully support your version of Bukkit.
**
** When working with blocks or undoing, chests will be empty, signs
** will be blank, and so on. There will be no support for entity
** and block property-related functions.
**
** Please see https://worldedit.enginehub.org/en/latest/faq/#bukkit-adapters
**********************************************

Expected Behavior

WorldEdit loading fine.

Reproduction Steps

  1. Use WorldEdit on a Mojang mapped jar
  2. Notice the adapters failing to load/be provided

Anything Else?

No response

commented

So to support that, it's need to export a second copy of the adapter in a different package / with different FQNs. If you can make a PR for that, then maybe

In my opinion, it would be easier to build an additional -mojmap jar alongside -dist, like Paper does, instead of attempting to throw everything into one jar. Considering it'll only target a small audience, as of this time being.
That appears to be a somewhat of straight forward PR, yet glancing over my office hours, this is not something I have much time to work and test on.

commented

the adapters gradle project already outputs a dev jar, it's just not bundled anywhere. you can add it to your dev runtime classpath and manually point it out via -Dworldedit.bukkit.adapater=com.sk89q...

commented

Is this even a supported state? Paper uses the Spigot mappings at runtime, so I don't understand when you'd have Mojang mappings.

commented

The paperclip bootstrap you download remaps, however, if you build it yourself invoking shadowJar, paperweight builds a mojang mapped jar for you to use.

commented

The main problem is I don't know how we'd support this in a simple way, the adapter is written under Mojang mappings but Paperweight transforms it. So to support that, it's need to export a second copy of the adapter in a different package / with different FQNs. If you can make a PR for that, then maybe, otherwise I don't think it's worth committing two copies of the adapter to the repository since this isn't something that should happen outside of dev.

commented

Yea not sure how this is a bug. Our dist jars (for every platform) explicitly only support running in dist envs. For Bukkit platforms, that means spigot-mapped CB/Spigot/Paper. We do have tasks that generate (i.e. actually output the intermediate) dev jars for Forge/Fabric. If you want to PR that for -bukkit that outputs the un-spigot-mapped adapter, feel free. But I don't think we want to include that in the dist-jar, just like the other platforms.