search

kangarko / Foundation

Foundation™ helps you create highly customized Minecraft plugins (based on Spigot/Paper API) that support multiple MC versions.
https://mineacademy.org
305 stars 63 forks source link

CitizensAPI redistribution #291

Closed fullwall closed 3 months ago

fullwall commented 3 months ago

I ask that you do not redistribute CitizensAPI as part of this library. You are not following the terms of the citizens license and your redistribution license is not compatible with GPL which violates the general Bukkit license.

me4502 commented 3 months ago

I do question whether the current Foundation maven setup, aside from the licensing issues, is actually a good idea either way. We had someone yesterday ask in the WorldEdit discord about an issue with their plugin, which ended up being caused by them shading the WorldEdit dist jar due to the Foundation setup.

The current setup of pushing to a new group ID, as well as pushing distribution rather than API jars (at least in the case of WorldEdit, I have not checked other plugins), can both cause some pretty major issues.

Is there a reason that the Foundation Maven repo can't instead mirror the repos that the dependency plugins use, with caching enabled for redundancy? That's a setup that we use for the EngineHub Maven repo, where we ensure that all of our dependencies (other than ones available via Maven Central) are always available by setting up mirroring & caching. This would prevent the differing group ID problem, ensure that the provides jars are the ones that the developers intend them to be, and also ensure that you're complying with any licensing requirements.

I am happy to make a separate issue if needed, I just felt that this fit well into the whole discussion topic of how redistribution is currently taking place

kangarko commented 3 months ago

Hello,

I am happy to comply and apologizes for the inconvenience. However due to company holidays I am unable to access workstation until 26th of May.

The reason for our current setup was to allow plugin developers access dependencies from Foundation. If I use the scope to "provided" than the children plugins won't see them. Hence we just default the scope to compile (or no scope) and let children plugin use "includes" clause in the shade plugin to only include Foundation and nothing else. I believe the issue discussed at your Discord was due to the lack of this part from pom.xml.

@me4502 I'd be very grateful if you could show me on how to do your proposal with maven - would that mean that plugin developers need to explicitly include all dependencies they want to use or would it continue to function as we have now?

Thanks, Matej

me4502 commented 3 months ago

Sure. So it'd functionally behave the same way from the perspective of the plugin developers, the changes would be made in the Foundation pom.xml, and within your Maven repo.

From what I can gather with your current setup, you're currently using a BitBucket git repo as a Maven repo? I feel this is probably the main blocker to having a proper setup here. As while I'm not familiar with it, I'm not sure it'd be possible to setup proper mirroring and caching purely with BitBucket.

The EngineHub Maven repo is hosted with Artifactory. We publish our plugin builds to our internal repo, and for any dependency repos we have (Paper, Spigot, Fabric, Forge, etc) we include them as remote mirrors within Artifactory. Then we have a "virtual repo" that basically includes the internal one, as well as any remotes, and that virtual repo is what we expose as https://maven.enginehub.org/repo/. Artifactory docs: https://jfrog.com/blog/how-to-set-up-a-private-remote-and-virtual-maven-gradle-registry/

This allows developers using WorldEdit to purely include the EngineHub Maven repo and the WorldEdit dependency, and automatically have WorldEdit's dependencies and dependent repos available to them, without them having to even know what they are.

So in your case, you'd setup a repo that you publish Foundation and any other MineAcademy resources to, mirror repos that mirror the repos of all of your dependencies (eg, the EngineHub maven repo for WorldEdit and WorldGuard), and then a virtual repo that ties it all together. Then the repo link people would use would instead be the one of the virtual repo, rather than BitBucket. So from the user's perspective, they're including Foundation and the MineAcademy repo, and continue not having to care about what Foundation imports as it'll all work out of the box.

That way you've removed any redistribution issues, you've removed the manual effort of having to actually upload those jar files, and you retain the benefits of the current setup.

kangarko commented 3 months ago

Can't thank you enough for detailing it out! We're going to be handling it this week. Thanks again!