Allow more flexibility in plugin name

[dumptruckman]

trafficstars

I have a library plugin that includes an external lib for plugins dependent on my plugin. In order to version incompatibility for plugins expecting a different version of that external lib, I've done some hackery to include the version name in my plugin's name. example-1.1. Unfortunately, the bStats website does not allow me to add this plugin to the site. Is it possible you can make the system a bit more lenient on plugin names?

[randombyte-developer]

I have a shared library accross my plugins, too. It's called kosp if you want to look at it. I use the gradle shadow plugin(j.rengemann) to directly copy kosp into the final plugin jar and additionally relocate the kosp package. It works beautifully and no incompatibility may occur.

[dumptruckman]

Unfortunately it's not that simple in my case. Take a look here for an explanation.

[randombyte-developer]

Great to see another one using Kotlin! My library has the same purpose as yours, just for Sponge (Kotlin + Sponge) ;)

So instead of shading the kotlin lib into every plugin jar you want the admins to download the lib jar and place it in the plugins folder?

[dumptruckman]

Yes. But this makes it so different versions of Kotlin can be loaded together in order to avoid incompatibility because some other plugin is shading in Kotlin without relocation. Plugins depend on libkt in their plugin.yml and on it in their build script instead of Kotlin directly.

[randombyte-developer]

Sorry, but I don't quite get why you make it so: Example:

• Lottery plugin, uses Kotlin 0.1, shades and relocates the Kotlin lib into the final jar and has to no dependencies on the original kotlin package
• Holograms plugin, uses Kotlin 1.0, shades and relocates the Kotlin lib into the final jar and has to no dependencies on the original kotlin package
• ServerSigns plugin, uses Kotlin 5.0, shades and relocates the Kotlin lib into the final jar and has to no dependencies on the original kotlin package

If a plugin doesn't relocate the Kotlin lib, it is their risk and their fault. If an unrelocated lib is put into the plugin folder it doesn't interfere with the plugins that only have a dependency on the relocated lib.

[MiniDigger]

using the plugin name to save the version is a hack. I don't think that bstats should support those hacks. why can't you just make a new 'kotlin-version' field in the plugin.yml? lol

[dumptruckman]

@randombyte-developer You misunderstand I think. The idea is that libkt is for people who don't want to (or can't - premium plugins for example) shade in the Kotlin stdlib. It's also for people who want to ensure that a specific version of the Kotlin stdlib is available without shading it themselves. Example:

• Lottery plugin, uses libkt-0.1, puts depend: [libkt-0.1] in their plugin.yml. libkt-0.1 plugin jar must be present and it provides a relocated Kotlin stdlib instead of Lottery.
• Holograms plugin, uses libkt-2.0, puts depend: [libkt-2.0] in their plugin.yml. libkt-2.0 plugin jar must be present and it provides a relocated (different relocation than libkt-0.1) Kotlin stdlb instead of Holograms.

However, because the Kotlin compiler automatically adds imports for certain Kotlin classes (kotlin.Metadata for instance), those packages must be relocated in Lottery and Holograms in order to match the packages that libkt provides.

Premium plugins have a 4 mB size limit so having to include the Kotlin stdlib themselves can be a burden.

@MiniDigger I am aware it is a hack. However, I don't see what that has to do with bStats. What about some plugin that chooses to use periods or dashes in their plugin name for non-hacky reasons? It would seem those plugins are not allowed on bStats.

[randombyte-developer]

Oh, I didn't know that the file size is a problem. That's interesting in today's times that storage is a limit. I would ask the people of that premium plugin distribution service to higher this limit for the reasons you stated here(incompatibility).

[MiniDigger]

the limit will not be changed any time soon. the suggested way of including such large libs is to download them manually and load them via a urlclassloader or promt ppl to add them to the class path via the -cp argument.

[Narimm]

Can I update this to mention the fact that - say for example I am adding a new Plugin - thats has existed for over 10 years - up until now it use the old Metrics so I am switching it to bstats - but when I add the plugin it says it already exists despite the fact there is no plugin by that name listed.. This presents a problem from the point of view its highly likely there will be 2 plugins with the same name that are completely different - I think it would be smarter to assign a Plugin a UUID on the website and initialize it Metrics metrics = new Metrics(plugin); metrics.setPluginID(<uuid>); metrics.addCustomChart(charts);

** Moved to a new #40

[Derkades]

And that you can obtain one such UUID by logging in and adding a plugin?

EDIT: You should probably create a new issue for this