[zeng-github01]

Summary

This PR introduces support for synthesizing Gradle-compatible userdev artifacts directly from Python-era Forge source archives (-src.zip, Minecraft 1.6.4 only now).
With these changes, Mavenizer can now feed legacy Python-era Forge versions into the processV2 pipeline (FGVersion.v1), allowing modern ForgeGradle / dev workspaces to build downstream mods targeting legacy versions seamlessly.

---

Changes

1. Python MDK to Userdev Synthesis (PythonForgeSource)

• Added extraction and layout synthesis from Python-era forge-*-src.zip into standard userdev.jar structure:
  • Repackaged MCP configuration files into conf/ (conf/packaged.srg, conf/packaged.patch, conf/packaged.exc, astyle.cfg, mcp_merge.cfg).
  • Added Access Transformer definitions (fml_at.cfg, forge_at.cfg) to src/main/resources/.
  • Extracted MCP CSV mappings into mappings/ (fields.csv, methods.csv, params.csv).
  • Bundled source trees (net.minecraftforge.*, cpw.mods.fml.*) and patch archives (fmlpatches.zip, forgepatches.zip).

2. Legacy Package Remapping (LegacyPackageMappings)

• Implemented stream/regex-based repackaging logic mirroring FML's legacy Python remapper:
  • Maps legacy flat package paths (net/minecraft/src/ClassName) to package paths defined in packages.csv.
  • Supports remapping unified patches (minecraft_ff.patch)
  • Properly handles inner classes ($) and optional CSV header formats.

---

Verification & Testing

• Artifact Validation:
  • Verified generated conf/ and mappings/ files against official Forge 1.6.4-9.11.1.964 userdev.jar releases.

[zeng-github01]

So far, I haven't found a way to generate devbinpatches.pack.lzma and binaries.jar.

It also doesn't support FF patches; I haven't found a solution for this yet.

Also, the tests need to be removed, as some of the test code corresponds to logic that existed before the refactoring.

[zeng-github01]

So far, I haven't found a way to generate devbinpatches.pack.lzma and binaries.jar.

It also doesn't support FF patches; I haven't found a solution for this yet.

Also, the tests need to be removed, as some of the test code corresponds to logic that existed before the refactoring.

Testing confirms that runClient for version 9.11.0.879 (the earliest version, 1.6.4, available on the official website) can now be executed. It is unclear what impact the absence of these two files might have.

In theory, this patch supports MC 1.6.1, provided that the corresponding mapping zip coordinates are available in ForgeMaven.

Or, generate mapping coordinates and files directly from src via a new commit.

@LexManos

[zeng-github01]

I am currently testing the patch's compatibility with Minecraft 1.5.2. It mostly works, though some necessary artifacts are missing—specifically the mappings.zip and mcp-1.5.2-srg.zip files, which I’ve attempted to generate locally. Since these manually generated files may not be perfect, it would be better if you could provide the official versions. I will submit a new set of commits shortly; please review and test them. The new patch includes functionality to generate mappings from the Python MDK, as well as a fallback mechanism when retrieving default mappings—let me know if you’d prefer I remove these.

[zeng-github01]

After some testing, I’ve confirmed that the refactored code still triggers the original Javac error in version 1.5.2. Since it prevents downstream projects from initializing, I’ve abandoned the effort to make this patch compatible with 1.5.2. I’ll leave it at this.

[zeng-github01]

This patch has been tested and is capable of booting Forge 1.6.2. It only requires the snapshot mappings zip and the mcp-1.6.2-srg.zip file.

and setting default mappings for 1.6.2

[LexManos]

Look, I haven't had time to sit down and process through all of this, and honestly its come down to motivation.
From the way it's presented it very much feels like an AI pass that hasn't actually understood why/how things work.

A large part of the dev of Mavenizer is figuring out what each 'era' of Forge actually is.
A couple of major things need to happen.

The mapping zip files need to be iterated/generated. This is as simple as going through all of the existing forge zips, and converting the conf folders to mapping zips, assign each a filename based on timestamp, then de-duplicating based on hash, and dumping a table of when changes happened.

That then gets turned into the default mappings table.

A similar process except for the python code. I need to know when (what forge version), and how (a diff between the code) the python code changed. That way we can adjust the mavenizer code as needed.

A table needs to be made for the ModLoader/ModLoaderMP dependencies as well so that we know what needs to be injected into the binary before decompiling for each Forge version.

A table for what Fernflower version is used is also needed, as that highly effects the decompile.

Same for what java version.

The python era support should be able to be done for all versions at the same time, as the python code didn't change that much over the time it was used. There should only be a handful of variants.

But ya, trying to synthesize the userdev jar is the wrong apprach to deal with python. It will only work for 1.6.4 as you've seen as FG1 was pretty much a straight port of the python code at that time.

devbinpatches.pack.lzma and binaries.jar.

Those files are not used in mavenizer, as we do the whole process through decomp, and those were used when doing the 'fast path' of setupCIWorkspace

[zeng-github01]

The initial version was written by AI, but following a subsequent review, it was brought into alignment with the existing workflow. After all, it’s not really realistic to expect a simple understanding of such a complex system.

The method of directly synthesizing userdev is actually applicable to the 1.6.x series; testing has confirmed that it also works for 1.6.2. You simply need to manually package mcp-1.6.2.srg.zip along with the corresponding mappings.

I am currently working on compatibility for older versions; however, versions prior to 1.6.x lack the fml.json file in their original MDK, which makes it impossible to resolve dependencies. In my local testing on other branches, I attempted to manually extract library coordinates from the 1.5.2 installation JSON and inject them into userdev, but this resulted in various recompilation errors.

I even discovered an issue where a function in the mappings had an SRG name but lacked an MCP name, yet the recompiled code contained references using the MCP name.

In short, it’s a real hassle; this patch is only compatible up to version 1.6.x, and anything earlier would require some breaking changes.

Since you haven’t responded for a while, I’ve made a number of adjustments—mostly removing unnecessary code that had been added by the AI. You can simply check the "Modified files" tab to see the changes.

[zeng-github01]

Look, I haven't had time to sit down and process through all of this, and honestly its come down to motivation. From the way it's presented it very much feels like an AI pass that hasn't actually understood why/how things work.

A large part of the dev of Mavenizer is figuring out what each 'era' of Forge actually is. A couple of major things need to happen.

The mapping zip files need to be iterated/generated. This is as simple as going through all of the existing forge zips, and converting the conf folders to mapping zips, assign each a filename based on timestamp, then de-duplicating based on hash, and dumping a table of when changes happened.

That then gets turned into the default mappings table.

A similar process except for the python code. I need to know when (what forge version), and how (a diff between the code) the python code changed. That way we can adjust the mavenizer code as needed.

A table needs to be made for the ModLoader/ModLoaderMP dependencies as well so that we know what needs to be injected into the binary before decompiling for each Forge version.

A table for what Fernflower version is used is also needed, as that highly effects the decompile.

Same for what java version.

The python era support should be able to be done for all versions at the same time, as the python code didn't change that much over the time it was used. There should only be a handful of variants.

But ya, trying to synthesize the userdev jar is the wrong apprach to deal with python. It will only work for 1.6.4 as you've seen as FG1 was pretty much a straight port of the python code at that time.

devbinpatches.pack.lzma and binaries.jar.

Those files are not used in mavenizer, as we do the whole process through decomp, and those were used when doing the 'fast path' of setupCIWorkspace

I agree that this isn't a general solution for the entire Python era. As far as I can tell, it really only applies to 1.6.x.

At the moment, I'm intentionally focusing on the lowest-effort and lowest-risk part first. The amount of special handling required is much smaller, and there is a clearer reference point in FG1.

For versions prior to 1.6.x, the challenge is no longer synthesizing a userdev-like environment, but reconstructing the original pipeline itself. That's an area I still need to research further, and I don't yet have an approach that I'm happy with.

[zeng-github01]

@LexManos I have tested compatibility for version 1.5.x, but version 1.4.7 is incompatible. I suspect this is due to incompatible runtime parameters for Fernflower.