Exact same build environment as in #45.
When trying to run Fabric 1.16.5 with an access widener placed in common/src/main/resources
and properly referenced in fabric/src/main/resources/fabric.mod.json
, I get the following crash:
[13:19:26] [main/ERROR] (FabricLoader) Uncaught exception in thread "main"
java.lang.RuntimeException: Missing accessWidener file example.accesswidener from mod examplemod
at net.fabricmc.loader.impl.FabricLoaderImpl.loadAccessWideners(FabricLoaderImpl.java:482) ~[fabric-loader-0.13.2.jar:?]
at net.fabricmc.loader.impl.launch.knot.Knot.init(Knot.java:145) ~[fabric-loader-0.13.2.jar:?]
at net.fabricmc.loader.impl.launch.knot.Knot.launch(Knot.java:71) ~[fabric-loader-0.13.2.jar:?]
at net.fabricmc.loader.impl.launch.knot.KnotClient.main(KnotClient.java:23) ~[fabric-loader-0.13.2.jar:?]
at net.fabricmc.devlaunchinjector.Main.main(Main.java:86) ~[dev-launch-injector-0.2.1+build.8.jar:?]
at dev.architectury.transformer.TransformerRuntime.main(TransformerRuntime.java:219) ~[architectury-transformer-5.2.83-runtime.jar:5.2.83]
I am using a very similar setup to what is suggested through the architectury-templates
template 1.16.5-forge-fabric-mixin.zip
.
Going a bit deeper into this, the function ModContainer#getRootPaths
suggests in its JavaDoc:
The paths may point to regular folders or into mod JARs. Multiple root paths may occur in development environments with -Dfabric.classPathGroups as used in multi-project mod setups.
Indeed, when adding the following to the VM options of the generated run configuration for IntelliJ, Fabric starts fine:
-Dfabric.classPathGroups=PATH_TO_PROJECT\fabric\build\resources\main;PATH_TO_PROJECT\common\build\resources\main
Of course, the fabric:runClient
Gradle task still does not work correctly since the fix does not apply there.
I think, this should be applied/changed automatically by the Architectury plugin.
Edit: I just noticed a minor caveat: FabricLoader now logs:
[13:50:43] [main/WARN] (FabricLoader) getRootPath access for examplemod 1.0.0 with multiple paths, returning only one which may incur unexpected behavior!
I think, it's worth fixing this anyway - I just wanted to let you know...