SrgToMcpRenamer uses hardcoded path for nested jars

[Su5eD]

The Issue

Currently, only nested jars under the META-INF/jarjar/ directory are deobfuscated by SrgToMcpRenamer.

InstallerTools/src/main/java/net/minecraftforge/installertools/SrgMcpRenamer.java

Line 132 in dd66a7d

processors.add(new ZipEntryProcessor(ein -> ein.getName().startsWith("META-INF/jarjar/") && ein.getName().endsWith(".jar"),

While this is the most common folder for nested jars, JarJar metadata defines nested jar paths as paths relative to the outer jar's root, and therefore nested jars can be located anywhere in the jar. This breaks mods that place their nested jars in other paths than the mentioned folder.

Expected behavior

SrgToMcpRenamer is able to deobfuscate any nested jars regardless of their location, as specified by JarJar metadata. Rather than assuming all nested jars are in the META-INF/jarjar/ directory, we should open the jar's JarJar metadata file and read nested jar paths from it.

[KitsuneAlex]

This seems like a good point

[LexManos]

Just like my other comment, this is used for dev time and dependencies shouldnt be bundled in dev time. Especially not obfuscated ones. But I can't fix this annoyance.
And the metadata is poorly designed/implemented in a lot of things. So if you want to go through and write a metadata parser that finds the correct path, then go for it. Its not important enough for me to care about. As i said, a lot of projects assume this base directory so deviating from it would most likely trigger issues elseware.

[KitsuneAlex]

That is fair, i wouldn't have made that comment after i heard your take on that kinda thing. But there's super rare cases where this might be relevant. I'd actually be down to writing a parser. Just feel like helping out a bit in general during my free time, i use Forge for free, i wanna give back a little, even if its something irrelevant to you :D

[LexManos]

Feel free, just don't expect me to care much :P