[Feature] FMJ Spec API

[SHsuperCM]

Following the conversation in #loom I wanted to bring this into an issue so I wont forget about it.

This is a feature request for either fabric loader or the fabric project as a whole in a separate "fmj spec" library that fabric loader would use. The idea is to have a proper public api for the fmj specification and for dealing with fmj files.
I believe the issue should be here as fabric loader is the main project that defines and uses the fmj file.

Currently the fmj is accessed directly through the json. What I am seeking is a layer of abstraction for interacting with it that is the same across all users of the spec, whether it be fabric loader, Loom or other 3rd party libraries needing to work with fmj.

When Loom builds a fabric mod, it adds included jar entries manually by modifying the built fmj with gson. It also pulls interface injection entries as well as access widener paths(for taws) when loading mod dependencies. The system for it is completely separate from the code in floader that implements the fmj spec which could lead to breakages. In addition, mods' buildscripts modify the version of the built mod manually using a gradle processResources which requires accessing and modifying through mentioning the file by name and expanding text in the file.

Another use case would be 3rd party libraries, an example for this would be my own plugin Fletching Table which, among other things, adds the ability to append entrypoints to the fmj which are collected from an annotation processor. Again, the way I have to access the entrypoints in the fmj is very informal and relies on the assumption of fmj specs.

The api I'm looking for should be able to read fmj spec, keeping a consistent access abstraction across (future)spec versions.
The api should allow modification as well as generation from scratch, to allow plugins such as Loom, 3rd party plugins or even the project's buildscript to change or append metadata to the built mod. Or even go as far as "datagenning" the entire fmj from the buildscript.

If added

• It should be used under the 2nd abstraction of fabric loader, to give mods runtime access to metadata through the existing, view-only api of floader(and to not break api) while also keeping in line with the same spec access as other projects.
• Loom should be using it to modify included jars and access values from mod dependencies.
• It should be an included and provided api when using Loom, to allow both 3rd party libraries and buildscripts to use it.
• Loom should ideally provide a formal place to modify the fmj to allow implementing things such as setting the version, setting dependencies, setting entrypoints or defining other fmj values(or even the entire fmj file if it doesnt exist yet). This means both api for plugins but also api for the buildscript(for example in the loom extension for the buildscript). It could also be used by Loom itself to streamline appending the included jars entries.
• The example mod and template mod generator should adapt to the new api by replacing the processResources block with formal modification of the mod's version in the final jar.
• Loom should be modifying the fmj earlier to let up to date values show up in the development environment mod (for Fletching Table I modified the json during the gradle classes run which happens before the mod is used in dev). This would let developers see a correct up to date picture of what the mod's metadata would look like in dev.
• Loom should be adding the accessWidener path to the fmj instead of having the dev define it in two places.

All of the above points are of course up for debate but these were the intended uses from within the fabric project itself.

Thank you for coming to my ted talk.