Duplicate detection of JiJ’d libraries that have the same name but different content

[Bawnorton]

FML doesn’t appear to handle duplicately named JiJ’d dependencies correctly when the content of said jars is completely different, the resolution appears to just check the name which is insufficient for duplicate detection as it leads to false positives.

https://mclo.gs/B76Yiye

[04:06:33] [main/WARN]: Attempted to select two dependency jars from JarJar which have the same identification: jar(mods/neruina-3.1.6+1.21.11-neoforge.jar) > jar(mods/neruina-3.1.6+1.21.11-neoforge.jar > httpclient-4.5.jar) and jar(mods/Geyser-NeoForge.jar) > jar(mods/Geyser-NeoForge.jar > httpclient-1.9.0.jar). Using jar(mods/neruina-3.1.6+1.21.11-neoforge.jar) > jar(mods/neruina-3.1.6+1.21.11-neoforge.jar > httpclient-4.5.jar)

[04:06:33] [main/INFO]: Found library file "httpclient-4.5.jar" [parent: neruina-3.1.6+1.21.11-neoforge.jar, locator: jarinjar]

java.lang.NoClassDefFoundError: net/lenni0451/commons/httpclient/HttpClient
	at FML Plugins//net.raphimc.minecraftauth.MinecraftAuth.createHttpClient(MinecraftAuth.java:47)

Lenni’s httpclient and apaches have the same name but have different content leading to the NCDFE

[lukebemish]

The name-based detection was necessary since -- if they lack a module-info -- non-mod libraries were loaded in a module with a name derived from the file name. I suspect that this is not as important nowadays -- after all, non-mod libraries won't be loaded modularly by default anyways since they default to being treated as LIBRARY. That said, how to handle duplicates at that layer isn't obvious if you don't have mod-ness or metadata yet.