Crash with Respackopts and LibJF about quilt-loader

[maximumpower55]

LibJF uses fabric loader's internals, ModContainerImpl to be more specific, so its not really fixable

[Julienraptor01]

LibJF uses fabric loader's internals, ModContainerImpl to be more specific, so its not really fixable

is it fixable on the dev side with really little changes ? (I've already talked with him but he responded me that he shouldn't have to do smth as quilt said it would support fabric mods. But if it only require small chnages i can try to ask him to still do it or to do a fork myself.)

[AlexIIL]

To be specific, LibJF creates entrypoint objects directly, which isn't exposed as functionality directly through either fabric-loader api or quilt-loader api. The closest approximation would be to use FabricLoader.getEntrypoints() - however this might not be sufficient, depending on why LibJF chose to create entrypoint objects directly.

[AlexIIL]

Upon closer inspection, it looks like LibJF (ab)uses language adapters to expose an even earlier entrypoint for mods to use. This means they are trying to get entrypoints too early for normal entrypoints methods - since they require language adapters to be setup.

I can't see an easy fix for this, since it depends on why LibJF exposes entrypoints that early.

[Julienraptor01]

From JFronny

The hacky parts in libjf are needed for manual ASM (for example in powerless, mAME or data-manipulation, which respackopts builds on) and mod injection (for example in modsmod or mixwork) with access to properly loaded configs, both of which are needed elsewhere

[AlexIIL]

Okay, in which case libjf is most likely entirely incompatible with quilt, since it interacts directly with lot more of fabric loader internals than just entrypoints - it's probably not going to be possible for us to support that.