StillGreen-san
commented
3 months ago personally im in the 'accept large plugin' camp at least until either 'minimizing' or 'dynamic downloading' are possible
the minify option of maven-shade-plugin for example can reduce the size from ~100mb (with ms graph sdk) to ~80mb. which is ok for an option you can just toggle but doesnt really move the needle
proguard i could not get to work properly, it always removed to much, so that the plugin would not load anymore
downloading the libs on demand seems like the thing that already exists as a library, but i did not search for it
this is not a direct request and instead intended for general discussion
the plugin is already on the larger side and adding more libraries to support additional services/protocols/features, will increase size further
there are multiple ways to handle it, each with there own tradeoffs
accept large plugin
no additional work required storage and bandwidth are abundant, so 100-200MB aren't that big of a deal, even if it is unusually large
hand rolling
only writing things absolutely needed by hand instead of using an existing library decreases size by not including unused code through big libraries but increases error surface and maintenance burden by having to implement things yourself may increase time required to implement a new feature by not being able to rely on abstractions from the libraries
minimizing / tree shaking
reduces the size by removing unused code from the jar after the jar has been build may increase build time needs proper configuration so it does not remove to much
possible options: maven-shade-plugin (already in the project) proguard r8 shakyboi JarShrink
dynamic downloading
only download dependency at runtime could also only download libs that are actually required by the user
as seen in the wild: luckyperms spigot (libraries setting in plugin.yml)