Skip to content

Conversation

AzureDoom
Copy link
Contributor

Fixes #104

@lukebemish
Copy link
Contributor

lukebemish commented Oct 7, 2025

The :common-compiled classes/resources are never actually used in the forge jar in prod, instead the same are used when compiled by :forge and so this seems like a strange fix? Can you share what the exact error is (aka, which task it's triggered in), because I suspect either (a) the mixin AP for some reason can't find a refmap association for stuff when running in the forge subproject and this fixes that somehow, in which case the AP still shouldn't be added to common (note that the APs output in common will only ever be used in dev!), or (b) this is actually a failure during compile of common in dev, in which case we should figure out how to turn off mixin remapping entirely for common. Either way, the AP probably shouldn't be present in :common (and frankly, given how awful the AP is let's keep it out of anywhere it's not needed, right?)

@AzureDoom
Copy link
Contributor Author

AzureDoom commented Oct 8, 2025

The :common-compiled classes/resources are never actually used in the forge jar in prod, instead the same are used when compiled by :forge and so this seems like a strange fix? Can you share what the exact error is (aka, which task it's triggered in), because I suspect either (a) the mixin AP for some reason can't find a refmap association for stuff when running in the forge subproject and this fixes that somehow, in which case the AP still shouldn't be added to common (note that the APs output in common will only ever be used in dev!), or (b) this is actually a failure during compile of common in dev, in which case we should figure out how to turn off mixin remapping entirely for common. Either way, the AP probably shouldn't be present in :common (and frankly, given how awful the AP is let's keep it out of anywhere it's not needed, right?)

The annotationProcessor was only added so that my common source would remap correctly when building my mod, as without it would fail to even build. I discovered this while working on my example mod here: https://github.com/AzureDoom/Azurelib-Rewrite-Examples/tree/1.20.1 to test some new features/bug fixes to Azurelib

Until I added both of these entries to my common build.gradle, the mixins from this commit (AzureDoom/Azurelib-Rewrite-Examples@dad749e) wouldn’t work in either dev or prod, since the mapping for the method couldn’t be located, as shown in the attached screenshot. Note this affected both Forge AND Fabric for me
image

@lukebemish
Copy link
Contributor

lukebemish commented Oct 8, 2025

Mmm. That sounds like it's likely the second scenario I described then; can you share the full error (the full Gradle log that is) please? Adding the AP to common is... Not optimal, given that it directly degrades performance if present. And given that the output of common compile is used nowhere in prod -- it's not bundled into the jar! -- it shouldn't be necessary and there's likely a better fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants