You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Jankson classes cannot be found, even when Jankson loads as a mod successfully? Causes Scarves incompatibility #2293
The game fails to load with the Scarves mod, citing a NoClassDefFoundError for blue/endless/jankson/JsonElement. This is particularly strange since Jankson is itself included jar-in-jar inside Scarves. Even if the Jankson jar is extracted and put into the mods folder independently, Scarves still fails to load, even though Jankson itself does load as a mod.
Steps to reproduce
Install Neoforge 21.1.248, Connector 2.0.0-beta.16+1.21.1, FFAPI 0.116.15+2.3.1+1.21.1, and Scarves 1.4.6.
Attempt to launch the game. It hits an error during loading. This error does not occur in a Fabric environment, only in NeoForge with Connector.
Open up the Scarves jar file and navigate to its META-INF/jars. There's a Jankson-Fabric-8.0.0+j1.2.3.jar included inside.
Extract the JIJ'd Jankson jar out into the mods directory and try to launch again. It will still fail with the same error.
Disable or uninstall the Scarves mod, then launch once more. The game will load fine, and Jankson will be present in the mod list.
I'm using Prism Launcher. I don't know of any other mods that require Jankson, so it's hard to say if this is an error that is extremely specific to the Scarves mod, or if it indicates some broader issue that could affect other mods. The idea that classes in a successfully-loaded mod might go missing in Connector, when they can be found without issue in Fabric, is very strange though.
In an environment with many more mods I was getting a launcher error which produced no Minecraft crash report or log, but when I went to a fresh installation I got the behavior described in this report. The launcher error in the messy environment still cited issues finding Jankson, so I assume that that behavior was probably just this same problem, only failing less gracefully.
Activity
Force unique module name for libraries