Suggestion: Shadow ProtectionLib

[Dymeth]

What do you think about including ProtectionLib inside FurnitureLib.jar with package relocation? Of course, we are talking about not launching ProtectionLib as a separate plugin, but using it as a simple dependency library.

This can be interesting for several reasons:

1. Simplification of the installation process. Instead of two jars, there will be one. You no longer need to extract the zip archive to install the update. The installation process will become more "classic" - this will reduce the chance of human error: for example, when FurnitureLib.zip is added to the plugins folder instead of FurnitureLib.jar and ProtectionLib.jar

2. Reducing confusion among server administrators regarding the ProtectionLib plugin. So, for example, people who are not familiar with ProtectionLib will not have any questions about the current version of the plugin. Currently, the ProtectionLib version has nothing to do with the FurnitureLib version from SpigotMC - this creates some confusion.

3. This will eliminate conflicts between different versions of ProtectionLib. Since ProtectioLib is positioned as a standalone library, it is likely that third-party plugins can use it as well. But due to frequent updates, there is a great chance to break compatibility with one of these plugins with the next update of ProtectionLib. But if the ProtectionLib is not intended for use by other developers, then why should it have a separate jar file?

I see the following complications that can arise after implementing ProtectionLib in FurnitureLib:

1. Issues related to ProtectionLib will most likely will added to FurnitureLib repository

2. It's not clear how to deal with some of the things from ProtectionLib: for example, metrics and the /protectionlib command. We can discuss this in this issue if it interests you.

[Ste3et]

I think The ProtectionLib is Frankensteins Monster, the lib have to mutch dependencys, i didn't like that idea that i should include ProtectionLib inside FurnitureLib because if i start to Work on the FurnitureLib ProtectionLib make always Problems to build my artifacts. Combining ProtectionLib back to FurnitureLib can fix some User Related Things but it didn't make my Working Process easier.

[Dymeth]

I think The ProtectionLib is Frankensteins Monster, the lib have to mutch dependencys, i didn't like that idea that i should include ProtectionLib inside FurnitureLib because if i start to Work on the FurnitureLib ProtectionLib make always Problems to build my artifacts. Combining ProtectionLib back to FurnitureLib can fix some User Related Things but it didn't make my Working Process easier.

ProtectionLib is currently being used as a provided dependency in the FurnitureLib project, right? So what specific artifact problems can using shadow cause with this dependency?

The only question I am currently unclear is how some of the ProtectionLib components should be called (for example, the onEnable() and onDisable() methods).

Can I try to implement my own proposal? If it doesn't pose any technical difficulties, will you be ready to accept my pull request? But, if you are not satisfied with this suggestion, this issue can be closed.

[Ste3et]

At the moment i try to figured out some new interest ideas. Shadow ProtectionLib is the smallest one, maybe the ProtectionLib works like PlaceHolderAPI with an central Database of supported ProtectionAddons who can installed on Runtime. These reduce some of the Version Conflicts but for the first i need to fix the Gradle Setup of ProtectionLib. There a bunch of errors inside the gradle build process atm. https://gitlab.com/Ste3et_C0st/protectionlib/-/jobs/1928399834