UniMixins

UniMixins

Mods
48.3k Downloads

Compat module >=0.1.9 breaks ExampleMod build

makamys opened this issue · 4 comments

commented

Originally posted by @drori200 in #15 (comment)

Currently with these changes early mixins loaded with GTNH's IEarlyMixinLoader aren't able to be loaded. Can't find the reason for this beside this error:

error: cannot access net.minecraftforge.fml.relauncher.IFMLLoadingPlugin
public class HavenCoreEarlyMixins implements IFMLLoadingPlugin, IEarlyMixinLoader {
       ^
  class file for net.minecraftforge.fml.relauncher.IFMLLoadingPlugin not found

This can also be reproduced by changing [email protected] to use UniMixins 0.1.11.

The issue comes from the compat module's cpw.mods.fml.relauncher.IFMLLoadingPlugin stub that allows the mod to be loaded on 1.8+. It causes no problems in production since mods only get added to the class path after FML, but during compilation UniMixins comes first, causing an error.

I'll have to move the stub into a separate, 1.8+-specific module jar (called compat-modern, perhaps) to fix it.

Alternatives considered
  • Have a copy of both 1.7's and 1.8's IFMLLoadingPlugin class in the jar. This is how Healer does compat. But it's too hacky for my liking, and we'd have to put them in every module jar.
  • Do some magic in code. Impossible since IFMLLoadingPlugin gets loaded before the mod is able to run any code.
  • Drop 1.8+ support. I don't want to do this since Mixingasm fixes an issue no other mod does to my knowledge on 1.12.
commented

According to GTNH discord user "alongstringofnumbers", MixinBooter by Rong had fixed this issue in their fork of UniMix. According to them it was fixed between MixinBooter 8.0 to 8.3.

Message link is here:
https://discord.com/channels/181078474394566657/603348502637969419/1157460064941125714

commented

To me it sounds like their issue was fixed because they switched from UniMixins to UniMix and/or MixinBooter (only the first includes the compat module), not because of any of Rong's changes.

commented

Not a perfect fix but maybe make it so Gradle will somehow be responsible for "pushing" the stub into the dev env's class path?
Another idea is just make a 1.7.10 developer usage only jar without the compat module (assuming that the -all jar works normally on 1.8+)

commented

You could probably work around the problem from the Gradle side, but a mod shouldn't require a special build script to depend upon when no other mod does, that just means your mod is broken.

Version-specific jars would technically work but bloat the jar count far too much (we'd need an all-dev and a compat-dev jar for both versions at the very least), at that point a single 1.8+-specific compat jar is still better.

  • 🚀1