Bundle Mojang mapped adapters as output jar
NotMyFault opened this issue ยท 6 comments
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
- Use WorldEdit on a Mojang mapped jar
- Notice the adapters failing to load/be provided
Anything Else?
No response
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.
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...
Is this even a supported state? Paper uses the Spigot mappings at runtime, so I don't understand when you'd have Mojang mappings.
The paperclip bootstrap you download remaps, however, if you build it yourself invoking shadowJar
, paperweight builds a mojang mapped jar for you to use.
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.
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.