Add plugin.yml for Bukkit, Spigot, Paper and Purpur and paper-plugin.yml for latest Paper

[Andre601]

Adds a plugin.yml file for Bukkit, Spigot, Paper and Purpur to the test/content/spigot/ directory.

The only required options in the example are:

• name (Used as identifier by the server)
• version
• main (Defines the Entrypoint of the plugin)

All other options are not required and may default to specific values.

The api-version, as mentioned in the comment below, only exists since Spigot 1.13. It only accepts major version patterns such as 1.13, 1.14 or similar. Only one version can be defined.
A plugin with an older version than the server may work on the server while printing a warning while a plugin with a newer version will fail to load on older servers (This info from what I gathered is apparently wrong. The version check does pretty much nothing outside enabling legacy API stuff or smth...) Servers using 1.12 or older are unaffected by this option.

The plugin.yml has been tested on a Paper server. Neither Paper nor Purpur make any changes to how the file is handled, therefore Spigot (And by extension Bukkit) may also work fine with it.

Update: Paper is working on a "Paper Plugin" API that utilizes a separate paper-plugin.yml (Added to this PR).
Most of the options remained the same such as name, version, main class, while things such dependency declaration received an overhaul and are different. The API is experimental as of right now.

Further information regarding the plugin.yml format: https://www.spigotmc.org/wiki/plugin-yml/

[Andre601]

I would like to quickly mention something I forgot:
In 1.13 did Spigot - and by extension Paper and Purpur - add an api-version: <string> option to the plugin.yml

It's basically used to tell the Server what API-version (MC-version) this plugin was made for initially, which results in warnings about possible incompatibility in newer versions (i.e. plugin has 1.18 defined but server is 1.19), and errors about unknown api-versions in older servers (i.e. plugin uses 1.19 but server is 1.18) making the plugin not start.
Server versions before 1.13 ignore this option as they didn't had it.

The option only accepts a single string (So no array or list can be defined) and it's only the 1.xx format, so 1.13, 1.14, etc.

I've added this not to the file, as the version-resolving can sure benefit from this option.

[Kira-NT]

That's not as bad as I thought! So, if I got it right, all these are forks of one original project? Is there a safe "default" option for the loaders input in case user did not specify it in their plugin.yml? Should it be spigot or something else?

What does api-version semantically mean? For example, does api-version: 1.13 mean >=1.13?

[Andre601]

That's not as bad as I thought! So, if I got it right, all these are forks of one original project? Is there a safe "default" option for the loaders input in case user did not specify it in their plugin.yml? Should it be spigot or something else?

The original was Bukkit (CraftBukkit), but was pretty much been replaced by Spigot after some general issues with the original devs from what I know.
Paper is a drop-in replacement for Spigot and supports everything Spigot does and Purpur is the same, but for Paper.

And default should preferably be Spigot. Bukkit is the original, but pretty much every plugin these days uses the Spigot API.

What does api-version semantically mean? For example, does api-version: 1.13 mean >=1.13?

Yes, tho on Spigot 1.14 and newer will it print a warning that the plugin is defining an older/outdated API version, but it won't prevent the plugin from loading

[Kira-NT]

Gotcha! Huge thanks for all the provided information and your PRs!

[Andre601]

Was wondering if I should replace the current fake IDs (unless there is actually a Curseforge project with ID 123456) with actual project IDs of existing ones?

Personally, I feel like that shouldn't be done here (Especially since people like to just copy-paste things anyways) and perhaps the other mod examples should have their IDs replaced too?

For Spigot do I know a resource that exists on Modrinth and Curseforge, but for Velocity and BungeeCord am I not sure about that.

[Kira-NT]

Don't worry, this is not part of documentation or anything, this is just for automated testing purposes

[Andre601]

Would like to point out that Paper now merged their PR for their paper plugin thing, so they now have a paper-plugin.yml file that is prioritized over the plugin.yml file (Which is still supported)

[Andre601]

I've gone ahead and added a paper-plugin.yml example to show the new dependency format for it. There may be future changes eventually. See PaperMC/Paper#8859 for possible new features.

[Kira-NT]

So, is it just a matter of time, or some drastic changes (which will affect this project) still may happen?

[Andre601]

So, is it just a matter of time, or some drastic changes (which will affect this project) still may happen?

I can't guarantee the file staying consistent. The paper plugin feature is still experimental, therefore there could still be breaking changes to it.
I have my doubts that the existing settings will see any breaking changes, but you never know unfortunately.

[Kira-NT]

Okie-dokie, noted

[Andre601]

Paper adjusted the format used for dependencies. I've updated the example to mirror this.

[Kira-NT]

Great! Does this updated format permit the attachment of a custom "mc-publish" field? Some parsers are set up to throw errors upon encountering unknown fields, so I'd like to confirm this.

[Andre601]

No idea tbh... I think it only checks for specific fields bein present and politely ignores everything else. Will do a quick check later.

[Andre601]

I've tested it and as expected does the server not care at all. It only cares for the necessary entries and everything else is kindly ignored.

[Kira-NT]

Okie-dokie, that's amazing