Add --output-json argument to expose program consumeable output info

[LexManos]

No description provided.

[Jonathing]

Before anything else, I think our JSON formats are starting to get a little out of hand. Mostly how we handle a good chunk of it within JSON Data Utils, a single library. That being said, I still want a library that makes it easy to (de)serialize JSON files that need to be shared between our tools. Should we split JSON Data Utils into several sub-utilities that each have the JSON formats for that specific tool or function? Or should each project carry some sort of "json-data" variant/artifact that is just the API for those classes?

[LexManos]

So I was thinking about that.
Which is why I just went with Map<String, String> right now.
What I was thinking about was making a 'minecraft-mavenizer-data' sub-project in this repo. That project would just have static classes which you can pass to GSON or whatever json parser yourself.
Exa:

public class Spec {
  public int version;
}

public class Output extends Spec {
  // Imagine fancy javadocs explaining things
  public Mappings mappings;

  public static class Mappings {
    public String version;
    public String channel;
    public Artifact csv;
    public Artifact obf;
    public Artifact srg;
  }
   
  public static class Artifact {
    public String artifact;
    public String file;
  }
}

Keeping a central json-data util for formats that arnt ours is fine.
Tho, we could split them into separate modules if we want, but i dont really think we need to.

[Jonathing]

Alright, that works for me. Artifact would be net.minecraftforge:minecraft-mavenizer-data I presume?

We don't need to split JSON Data Utils for formats that aren't ours. Just specifically the ones that our ours need to be abstracted away. Especially things like Patcher/userdev config.

[LexManos]

Alright, that works for me. Artifact would be net.minecraftforge:minecraft-mavenizer-data I presume?

Yup, because both gradle hating classifiers, and the format not updating often, having it as a separate artifact would be the way to go.

[Jonathing]

Ship it.

[LexManos]

Alright, so this is shipped the current spec is:

{
  "spec": 1,
  "key": "value"
}

A simple String Key, String Value map. All entries except spec are optional.
Current keys are:

• mappings.channel - The Mapping channel name, "parchment" or "official"

• mappings.version - The sanitized mapping version, EXA: 1.21.11 for official or a sanitized version for parchment.

• mappings.srg.artifact - The maven GAV for a mapped to srg file, suitable to be queried from the output maven repo

• mappings.srg.file - The path to the mapping file, bypasses need to to look it up in the output maven repo

• mappings.obf.artifact - same as above but mapped -> obf

• mappings.obf.file - same as above but mapped -> obf

• mappings.csv.artifact - Same as above but for the classic srg->mapped csv zip file use in old toolchains

• mappings.csv.file - Same as above but the actual file