WorldEdit Version

7.3.10-beta-01

Platform Version

Paper version 1.21.4-72-main@daddcf6

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

When running under recent Paper versions, WorldEdit is unable to locate js.jar when it is installed in the documented location.

If js.jar is placed in either the plugins or plugins/WorldEdit directories, WorldEdit always reports that it cannot find it (worldedit.script.missing-script-engine\nworldedit.script.please-see).

strace shows that Paper's remapping is having an impact on the path WorldEdit is checking:

2043494 21:23:43 stat("/opt/clod-mc/minecraft/plugins/.paper-remapped/js.jar", 0x7f757a90cb00) = -1 ENOENT (No such file or directory)
2043494 21:23:43 stat("/opt/clod-mc/minecraft/plugins/.paper-remapped/WorldEdit/js.jar", 0x7f757a90cb00) = -1 ENOENT (No such file or directory)

These are the only two references to js.jar during startup.

Sure enough placing js.jar in plugins/.paper-remapped enables craftscript, but that's less than ideal.

Expected Behavior

craftscript should work when js.jar is installed in plugins/WorldEdit

Reproduction Steps

1. install a recent paper version (eg. 1.21.4+)
2. install WorldEdit and the Rhino runtime
3. create a test craftscript
4. try to execute the script in game

Anything Else?

No response

this is basically working as expected. we don't really have any control over classloading, if paper loads the jar from another dir than plugins, that's where the classloader will look for classpath deps from the manifest. at most we can add a note to the documentation.

i suppose another alternative would be using something like the spigot library loader to download it automatically at runtime, which relieves the burden from the user to do anything, but i'd rather not depend on that particular spigot "feature".

or we could do as we do on NF/Fabric and just bundle it entirely. though i think that also has some issues as we don't relocate or anything. i remember someone reporting this can cause conflicts on forge, not sure if NF/Fabric(/Paper) do modules differently (NF might have inherited that behavior from FML, dunno).

Thanks for the quick response and clarification of the issue.

I'll check with Paper to see if there's any suggestions from them.

fwiw, modifying the classpath manually to account for the folder change works:
open up the jar, find /META-INF/MANIFEST.MF, change WorldEdit/js.jar under Class-Path to ../WorldEdit/js.jar
will discuss with paper peeps on if we can or want to do that automatically, first time I am seeing this feature of java being used like this in plugins
the easiest solution of course is to provide a mojang mapped download of worldedit :D

oh yea i was thinking about modifying the manifest and totally forgot you can just use the relative parent. guess that would be another workaround too, we could just add more classpath entries.

also uh yea this dates back 15 years to hmod. there was no support for things like libraries, very limited support for things like shading (we uh, may have still been using ant at the time?), and we didn't want to bloat the jar with the rhino dep most people wouldn't even use.

I think "the paper way" (tm) of this would be a config option "enable-rhino: true" or "js-engine: rhino" and then using the plugin loading mechanism to optionally load the lib, if the config is set. you can use that api without having a paper-plugin manifest since may last year: PaperMC/Paper#10758