Per-file loader for eventual Hangar support

[Andre601]

Assuming this action would integrate HangarMC support, how could we define loaders per file?

The platform allows to upload up to 3 individual files, which each can have their own platform/loader defined.
This with the current setup of mc-publish would already throw a wrench in existing setups.

Not only would we need a separate job/step for cases like when using a matrix strategy, but also now need a way to define a different platform/loader for a specific file.

So the question I have is, how could such a thing look like?

I believe that a syntax adobted from the new dependencies format could be used here for the files themself, allowing a format like:

files: |
  build/libs/plugin-paper.jar{platform:paper}
  build/libs/plugin-bungee.jar{platform:waterfall}
  build/libs/plugin-velocity.jar{platform:velocity}

or for simplicity sake maybe a file.jar@platform format instead?

Either way, the current way of how mc-publish defines loaders wouldn't allow us to upload multiple jars in one release with different platforms defined for each, so a way for it should be found eventually.

[Kir-Antipov]

First of all, I want to tell you, that under no circumstances I'm gonna re-write the whole project again just because of Hangar. But it does not mean that I don't want to implement support for it at all. With that said, let's continue.

Hangar API is quite weird, and it's not currently documented (the project is in beta, so we can give them a free pass on that tho), so I have problems parsing their example:

{
  "version": "string",
  "pluginDependencies": {
    "additionalProp1": [
      {
        "name": "string",
        "required": true,
        "namespace": {
          "owner": "string",
          "slug": "string"
        },
        "externalUrl": "string",
        "platform": "PAPER"
      }
    ]
  },
  "platformDependencies": {
    "additionalProp1": [
      "string"
    ]
  },
  "description": "string",
  "files": [
    {
      "platforms": [
        "PAPER"
      ],
      "externalUrl": "string",
      "url": true
    }
  ],
  "channel": "string"
}

Therefore, I cannot for the love of god understand the relation between platforms and files. Is it One-to-One? Is it One-to-Many? Because if it's One-to-One, the solution is trivial and the problem just doesn't exist in that case.

[Andre601]

The API is really stupid. Like you have to do a separate GET request with your API token first in order to get a new, temporary token to do actual API requests with... While every sane API in existance only needs one token.

But either way, the example you have seems wrong. Because the one they once shared with me, has a JSON structure like this:

{
  "version": "1.0.0",
  "pluginDependencies": {
    "PAPER": [
      {
        "name": "ViaBackwards",
        "required": true,
        "namespace": {
          "owner": "ViaVersion",
          "slug": "ViaBackwards"
        }
      },
      {
        "name": "Maintenance",
        "required": false,
        "externalUrl": "https://github.com/kennytv/Maintenance"
      }
    ],
    "WATERFALL": [

    ]
  },
  "platformDependencies": {
    "PAPER": [
      "1.18",
      "1.19"
    ],
    "WATERFALL": [
      "1.19"
    ]
  },
  "files": [
    {
      "platforms": [
        "PAPER"
      ]
    },
    {
      "platforms": [
        "WATERFALL"
      ],
      "externalUrl": "https://somedownloadurl.com"
    }
  ],
  "channel": "Release",
  "description": "My cool description!"
}

The pluginDependencies and platformDependencies is sorted by platforms while files mirrors the files you upload in the same order.

That's how I understand this system anyways... It really sucks and if it wasn't for this code example for Java would I've never bothered with uploading to their platform at all...

[Kir-Antipov]

My previous example wasn't really my own, but rather a demonstration on their part. To be fair, its structure is akin to yours, but there was confusion regarding what "additionalProps" were supposed to represent.

Upon further inspection, I've identified additional issues. Every platform entry carries its unique set of dependencies and a distinct list of "game versions" (i.e., Minecraft versions), among other things. Essentially, every significant input of mc-publish requires reevaluation, not just loaders, as you've proposed.

To clarify yet again, mc-publish was not designed to compensate for a user's disinclination to work with matrices or simply duplicate their configurations. The tool isn't intended to become so complex that one needs a degree to operate it because of features that can be accomplished without its intervention. The fundamental principle of mc-publish is to propagate a SINGLE new version across multiple different platforms. This results in a structural incompatibility with Hangar - they perceive multiple distinct publications as a single version and currently mandate simultaneous publication of these versions. As you've discerned, we cannot adhere to this requirement without a complete overhaul of our current system.

I must stress that I am not inclined to rewrite the entire project, nor do I wish to alter the fundamental abstraction upon which the entire project is founded, especially not because of a single project in beta testing.

However, a viable solution could materialize if Hangar implements the PATCH method for their versions route - a change I am hoping is imminent and not an issue of whether it will be adopted at all. With this feature, mc-publish could modify an existing version in sequential calls, attaching new sub-versions to it. Thus, you could consider courteously inquiring when Hangar plans to introduce this functionality, as it would give us a rough estimate of when and how we might incorporate support for Hangar.