-
Notifications
You must be signed in to change notification settings - Fork 17
Add validation for main class and api version #52
base: master
Are you sure you want to change the base?
Add validation for main class and api version #52
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
@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. |
@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? |
@stephan-gh Yes absolutely! |
@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 |
@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. |
Yes it works cross organization. https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository
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. |
@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! |
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. |
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. |
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. |
@rainbowdashlabs Sorry for the delay, I've been really busy with other projects. I have now added a note to the README that points to your repository. Once you have published a release on the new repository, I'll check if I can add a note to the Gradle plugin portal as well, and will probably archive this repository. Thanks a lot for taking over the maintenance of this plugin! |
* [skip ci] Update build.yml * Update publish.yml
* [skip ci] Update build.yml * Update publish.yml
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…-dataformat-yaml to v2.18.1 (Minecrell#8) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…rell#7) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…ule-kotlin to v2.18.1 (Minecrell#9) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…necrell#13) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
After a lot of back and forth its finally done and published on gradle plugin portal. |
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..