Bastian/bstats-metrics

Can you deny specific metrics from specific versions?

Andre601 opened this issue · 6 comments

Because of an older version are the metrics of my plugin completely messed up (see #80 for full context) and I now would like to deny those metrics from being displayed/rendered in some way, so that the metrics are fixed.
Is there a way to reset the metrics and make bstats not render/handle metrics from specific older versions?

Unfortunately that's not possible.
In your case, I would just recommend to delete the chart and create a new one with a different id.

In your case, I would just recommend to delete the chart and create a new one with a different id.

Would this cause any errors in the server/proxy console when the metrics are submitted?

No, the data will just be ignored by the backend.

Okay thanks for this info.

And while you're here would I like to ask a (hopefully easy to answer) question:
You may already know that I have a project that is split into three separate modules: Core, Velocity and BungeeCord.

I now use bstats-base in the Code module to have a getPie() method which returns a new DrilldownPie instance.
My question now is, should I relocate this base library or leave it as is? I'm not sure if relocating it would cause unwanted issues when compiling the plugin instances...

I now use bstats-base in the Code module to have a getPie() method which returns a new DrilldownPie instance.

Do not add the base module directly. It's unncessary because it's already included as a transitive dependency with the other bStats Metrics flavours.

My question now is, should I relocate this base library or leave it as is? I'm not sure if relocating it would cause unwanted issues when compiling the plugin instances..

You should relocate everything that inside the org.bstats package or in one of its subdirectories (use <pattern>org.bstats</pattern>). You will only run into problems, if you use more specific relocate rules (e.g., do not use <pattern>org.bstats.bukkit</pattern>).

See #82 (comment) for why it isn't that simple.

I can't and won't have multiple BStats dependencies in my core as it would only make it bloated without reason, once I build the jar files.
And I do use org.bstats as pattern, so don't worry about this.

You can see my current setup of everything here, to get yourself a picture of my situation: https://github.com/Andre601/OneVersionRemake/tree/feature/move-drilldownpie-method