[Enhancement] Avoiding having multiple Minecraft jars in multi-module development environment if possible

[qouteall]

In multi-module dev env (such as Fabric API dev env), if any access widener or interface injection is used (including transitive access widener), the subproject will have its own Minecraft jar. This results in having multiple Minecarft dependencies in the dev env and cause troubles in development:

• When searching usage to a MC thing, the IDE will show duplicated results
• Debugger not handling breakpoints in MC code correctly (in IntelliJ IDEA, putting a breakpoint in one submodule's minecraft jar's code, then when breakpoint hits, IDEA may show another minecraft jar's code)
• When running genSources, the same minecraft jar is decompiled for multiple times

It would be ideal that multiple submodules share one minecraft dependency when they have the same access widener and interface injection settings. If it's hard to implement, Loom can provide an experimental option to force it to share one minecraft jar.

[embeddedt]

Just wondering if you ever found a workaround for this? I have the same problem.

[qouteall]

@embeddedt My current workaround (told by modmuss) https://github.com/qouteall/fabric-loom/commit/4552b0446eed146bfac9e16bc0fe9e9edd72b601

This is the fork of loom that I am currently using. This will make it to have only one minecraft jar in dev env (but still has duplicated decompilation). It also makes debugging break but can be workarounded by removing source jar in IDEA.

[modmuss50]

This was done

[qouteall]

If one subproject has accesswidener that's all-transitive, and all other projects including the root project depends on that subproject, the current version of loom still does merge the Minecraft jar. This can be workarounded by putting the transitive AWs into another dev env.