Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

General notes on multi-platform Jars and supporting more server types in a manageable way #170

Open
p0t4t0sandwich opened this issue Feb 16, 2024 · 0 comments

Comments

@p0t4t0sandwich
Copy link

p0t4t0sandwich commented Feb 16, 2024

My general use case here is that the majority of my plugins/mods support all modding/plugin APIs in one Jar, so it's a bit of a pain to include metrics for 4 different implementations in a reasonable manner (my current implementation works, but is a bit sketchy imo).

If bStats ever expands to more server types, it should have a generalized implementation available at bStats-Metrics, allowing for it to be easily expanded upon, probably using something similar to this:

public class Metrics {
    private static Supplier<Integer> playerCountFunc = () -> 0
    
    public static setPlayerCountFunc(Supplier<Integer> playerCountFunc) {
        this.playerCountFunc = playerCountFunc
    }
    
    // ... The rest of the Metrics class
}

Or alternatively, bStats could ship all the logic in one dependancy that can be shaded, that checks the server type/version and applies the right methods automagically.
The jump to multi-platform is a bit much tbh, but after the initial setup it's a lot nicer to maintain, given that everything except for platform-dependent methods is common code.

If bStats ever goes that route, the server type could be another field in the API, allowing for developers to just set up any multi-platform plugin with the same pluginId.

Edit:
Wrote up a generalized example here:
https://github.com/p0t4t0sandwich/TaterLib/blob/dev/common/src/main/java/dev/neuralnexus/taterlib/bstats/MetricsAdapter.java
Main idea is to check what platform the server is running on, then use whatever helper class to safely get the proper platform methods.

The main future maintainability concern here will obviously be Forge, as you can't leverage intermediaries like you can with Fabric to get multi-version support from one artifact, though if multi-platform support were to be implemented, I'd be willing to take on Forge and create some decent abstractions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant