"Failed to read accessWidener" in 0.10

[quiqueck]

I just started to conver some mods to 21w40a. Everything appears to compile fine, but when I start the client (using gradlew runClient or starting it from IntelliJ) I get the following error:

Exception in thread "main" java.lang.RuntimeException: Failed to read accessWidener file from mod fabric-screen-handler-api-v1
at net.fabricmc.loader.impl.FabricLoaderImpl.loadAccessWideners(FabricLoaderImpl.java:443)
at net.fabricmc.loader.impl.launch.knot.Knot.init(Knot.java:122)
at net.fabricmc.loader.impl.launch.knot.Knot.launch(Knot.java:68)
at net.fabricmc.loader.launch.knot.KnotClient.main(KnotClient.java:28)
at net.fabricmc.devlaunchinjector.Main.main(Main.java:86)
Caused by: net.fabricmc.accesswidener.AccessWidenerFormatException: line 1: Namespace (intermediary) does not match current runtime namespace (named)
at net.fabricmc.accesswidener.AccessWidenerReader.error(AccessWidenerReader.java:281)
at net.fabricmc.accesswidener.AccessWidenerReader.read(AccessWidenerReader.java:90)
at net.fabricmc.loader.impl.FabricLoaderImpl.loadAccessWideners(FabricLoaderImpl.java:441)

The Mod I am working on does not use any accessWideners. I alsow cleared my entire build environment to make sure that it is not related to cached data or any game-config. Is this a Bug or something I am missing?

[modmuss50]

Can you post your build.gradle specifically the part where you depend on fabric api?

[quiqueck]

Here are the versions I am using:

loom_version=0.10-SNAPSHOT
minecraft_version= 21w40a
loader_version= 0.12.1
fabric_version = 0.40.8+1.18

I am using mojang mappings

[quiqueck]

This is the snippet from my build.gradle

archivesBaseName = project.archives_base_name
version = project.mod_version
group = project.maven_group
def local_bclib = findProject(':BCLib') != null

dependencies {
    minecraft "com.mojang:minecraft:${project.minecraft_version}"
    mappings minecraft.officialMojangMappings()
    modImplementation "net.fabricmc:fabric-loader:${project.loader_version}"

    modImplementation "net.fabricmc.fabric-api:fabric-api:${project.fabric_version}"

    println "Using local BCLib: ${local_bclib}"
    if (local_bclib){
        compileOnly(project(":BCLib"))
        modRuntimeMapped(project(":BCLib"))
    } else {
        modApi "com.github.paulevsGitch:BCLib:${project.bclib_version}"
    }
}

[modmuss50]

modRuntimeMapped(project(":BCLib")) Is not something you should be doing, this should be runtimeOnly project(":BCLib") Even then it would just be api project(":BCLib") to match what you have when not using the project. I would try fixing this, however I am doubtful this is causing that issue.

Running ./gradlew --refresh-dependencies would be a good thing to try as well.

[quiqueck]

Yup, makes sense :)

I fixed it and did called./gradlew --refresh-dependencies. Unfortunately the error is still the same.

[quiqueck]

Hm, If I do not use the local project, but a compiled Version of bclib the error goes away.

Using the local project does work when using Loom 0.9 or earlier.

[Juuxel]

Using the local project does work when using Loom 0.9 or earlier.

This is the key here. (Warning: heavy Gradle-ese ahead.) 0.10 made the default outgoing configurations (or "variants"), meaning apiElements and runtimeElements, export the remapped mods so that publishing would work as expected. This has the side effect of forwarding intermediary dep jars, which is causing your crash.

This means that you either need to use a custom outgoing configuration with dev/unmapped jars and depend on that, or modSomething project('theproject') (this one is a bit cursed with the useless remapping).

[quiqueck]

Ah, that makes sense.
I think I know what I'll have to change then :)

I really appreciate the fast help! :)

[quiqueck]

I figured using

if (local_bclib){
  modImplementation project(":BCLib")
} else {
  modImplementation "com.github.paulevsGitch:BCLib:${project.bclib_version}"
} 

should be a quick fix. And that change makes the error go away as expected. However, it does not pick up changes made to the source of the subProject. I have to manually issue :BCLib:build to include changes. The old version on loom 0.9 did automatically add the changed dependency when the source code was altered.

[Juuxel]

Yeah, that's because of mod* configurations' caching. You can use a custom outgoing configuration instead, which doesn't cache project dependencies (mod* configs caching them is really a bug). General instructions (these should work for most projects):

This in the library subproject:

configurations {
    dev {
        canBeResolved = false
        canBeConsumed = true
    }
}

artifacts {
    dev jar
}

And this in the consuming subproject:

dependencies {
    implementation project(path: ':theProjectNameHere', configuration: 'dev')
}

[quiqueck]

Sorry for the delay and thanks for the sample (which appears to work as it is supposed to). And thanks again for the really fast and in depth help!