Skip to content
This repository has been archived by the owner on Dec 7, 2024. It is now read-only.

Add validation for main class and api version #52

Open
wants to merge 25 commits into
base: master
Choose a base branch
from

Conversation

rainbowdashlabs
Copy link
Contributor

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..

@rainbowdashlabs rainbowdashlabs requested a review from booky10 June 4, 2024 18:52
Copy link
Contributor

@booky10 booky10 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@rainbowdashlabs
Copy link
Contributor Author

@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
Copy link
Member

@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
Copy link
Contributor Author

@stephan-gh Yes absolutely!

@stephan-gh
Copy link
Member

@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
Copy link
Contributor Author

@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
Copy link
Contributor Author

rainbowdashlabs commented Aug 26, 2024

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
Copy link
Member

@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
Copy link
Contributor Author

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
Copy link
Member

stephan-gh commented Sep 1, 2024

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
Copy link
Contributor Author

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.

@stephan-gh
Copy link
Member

@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!

rainbowdashlabs and others added 12 commits October 31, 2024 11:28
* [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>
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>
renovate bot and others added 8 commits October 31, 2024 15:18
…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>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants