Add validation for main class and api version

[rainbowdashlabs]

This PR adds additional validation for the main class and the api version for bukkit based plugin yamls.

One of the most common pitfalls for beginners is the api version, which they thinks is equal to the servers version. This PR aims to assert those mistakes already on build time.

The second common pitfall is (Beside entering a completely invalid path) using the paper, spigot or bukkit namespace for the main, which is not allowed by at least paper based servers (Didnt bother to check spigots code). Since this is in general a best practice I see no issue in enforcing this already on build time.

Ideally we could also check that the entered path to the main class is in fact existing in the sources, but I lack the knowledge in gradle plugins to do this, so I didnt do this..

[booky10]

👍

[rainbowdashlabs]

@stephan-gh This PR still exists c: I would also volunteer to step is as a maintainer for that plugin if you just lack the overall time to maintain it. There are still upcoming changes to paper and spigot and this plugin will most probably never reach a feature complete status, so it really needs an active maintainer.

[stephan-gh]

@rainbowdashlabs Sorry for the delay and not being very active here. Unfortunately, I don't have much time for maintaining Minecraft-related projects anymore. Would you still be interested in stepping in as maintainer?

[rainbowdashlabs]

@stephan-gh Yes absolutely!

[stephan-gh]

@rainbowdashlabs Thanks, that would be much appreciated! Did you already have a specific setup in mind?

If I remember correctly, the Gradle plugin portal does not allow multiple accounts to publish a plugin, so you would still be dependent on me to publish it. Ownership transfer is possible, but requires contacting them. And in that situation, I'm not sure if it even makes sense to continue using my personal net.minecrell namespace. Perhaps it would be easiest if I direct everyone to your fork? I'm not sure what's the best/easiest way in this case...

[rainbowdashlabs]

@stephan-gh Iirc moving a repo to some other namespace causes github to redirect. at least thats the case when renaming inside a organization. So I kinda would move it to my own namespace in gradle if they let me.
Another option would be to set me as a maintainer here and publish wia a workflow that is using a repository secret. That was I could publish via a workflow.
But the more future proof would probably either forking and redirecting or moving the repo and hoping that github also redirects cross organization.

[rainbowdashlabs]

Yes it works cross organization. https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository

All links to the previous repository location are automatically redirected to the new location. When you use git clone, git fetch, or git push on a transferred repository, these commands will redirect to the new repository location or URL. However, to avoid confusion, we strongly recommend updating any existing local clones to point to the new repository URL. You can do this by using git remote on the command line:

So moving it to my eldoria organization would redirect all links to this repo to the new one, which would be the ideal outcome probably.

Regarding gradle portal: A plugin can be republished if the original plugin is dead (Which is the case here pretty much) and receives no further updates. So I dont think it would be an issue to publish it to a new namespace in the gradle plugin portal. Especially when this repository is gone aka redirects to my repository now.

[stephan-gh]

@rainbowdashlabs I think publishing the plugin under a new namespace on the Gradle plugin portal should work fine.

Thinking about it some more, I'm slightly concerned transferring the entire GitHub repository to a different owner right away. I'm sure you can maintain it much better than I was able to in the last year(s), but we also did not have many interactions yet. I just want to make sure that the current state/history remains available forever and some future owner (not necessarily you!) does not delete it for some reason. I hope that is understandable. :)

There are not many existing open issues and pull requests here that would be important to continue in a new repository. If it's fine for you, perhaps it would be easiest if you fork (or push to a new repository) and I just archive this one and point everyone to your repository in the README?

Alternatively, I can add you as collaborator here and we check transferring the ownership sometime later.

What would you prefer?

I'm sorry for the extra trouble. I very much appreciate you volunteering to step in as a maintainer!

[rainbowdashlabs]

I just want to make sure that the current state/history remains available forever and some future owner (not necessarily you!) does not delete it for some reason.

I understand your concern. I would recommend to transfer it and fork it to your organisation again under a slightly different name, to not brek the redirect, since my biggest concern ist probably discoverability of the new active fork aka repository.

But if you don't want this I would more lean towards forking and archiving the original one with a note.

[stephan-gh]

I think I would prefer to archive this repository and add clear notes that the project is now maintained somewhere else (and by someone else). We will need to do this anyway for the Gradle plugin portal, since a redirect isn't possible there. I'll make sure that the notes are prominently visible so that there is no confusion.

I'm quite busy the next week, if you send me the link to the new repository location I'll update the descriptions on GitHub and the Gradle plugin portal after that.

Thanks for all your help! Let me know if you have any questions about the project setup.

[rainbowdashlabs]

The new repository is here https://github.com/eldoriarpg/plugin-yml. Gonna try to apply for the gradle plugin portal next week probably once the notes on that repository are up.