Describe the bug
Currently, Prism uses SOUT in some places, instead of using its plugin logger:

survival          | [21:37:08 INFO]: [Prism] [STDOUT] Elixr: Loaded items directory
survival          | [21:37:08 WARN]: Nag author(s): '[AddstarMC, add5tar, Narimm, viveleroi]' of 'Prism' about their usage of System.out/err.print. Please use your plugin's logger instead (JavaPlugin#getLogger).

To Reproduce
Just start Prism on latest PaperMC server.

Expected behavior
No nag is printed because Prism uses logger properly

Server (please complete the following information):

• Prism Version: 2.1.8-SNAPSHOT-224
• Server Type: Paper
• Server Version: 1.17.1, build 173

I would argue that in some cases using SOUT particularly in error reporting is relatively ok - Logger require static configuration and if for some reason that hasn't happened using them in a Static class is going to be bad. This is just another example of Paper's author group being anal, and creating needless annoyance for plugin authors. In this case the use of SOUT was entirely intentional - originally this class was loaded statically before Prism.onEnable() was even called... thus the logger was not ready and calling it would throw a NPE and cause the plugin not to load. Its not a bug at best its arguably poor practice ( not using SOUT - but loading it statically) which has been fixed. In this case the applied fix should be fine (now it wasnt prior to refactor)

I would argue that in some cases using SOUT particularly in error reporting is relatively ok - Logger require static configuration and if for some reason that hasn't happened using them in a Static class is going to be bad. This is just another example of Paper's author group being anal, and creating needless annoyance for plugin authors. In this case the use of SOUT was entirely intentional - originally this class was loaded statically before Prism.onEnable() was even called... thus the logger was not ready and calling it would throw a NPE and cause the plugin not to load. Its not a bug at best its arguably poor practice ( not using SOUT - but loading it statically) which has been fixed. In this case the applied fix should be fine (now it wasnt prior to refactor)

Hi,

I'd like to point out that the established standard in the entire Java ecosystem is to create a logger per class instead in these cases. That's very much a possible fix for the issue at hand. See for example:

https://github.com/spring-projects/spring-framework/blob/b595dc1dfad9db534ca7b9e8f46bb9926b88ab5a/spring-web/src/main/java/org/springframework/web/server/handler/ResponseStatusExceptionHandler.java#L44

https://github.com/brettwooldridge/HikariCP/blob/b5f5700e2dfdb23be9c7d01722df26eff134b1ef/src/main/java/com/zaxxer/hikari/util/DriverDataSource.java#L35

https://github.com/eclipse/jetty.project/blob/jetty-10.0.x/jetty-http2/http2-server/src/main/java/org/eclipse/jetty/http2/server/HTTP2ServerSession.java#L45

Notably, Log4j and Slf4j's APIs both include helpers for logging exceptions and whatnot as well.

As I said its been fixed my point was that adding clutter to the output just to make this point is akin to the hole paper api advertising issues that people report constantly...its a PITA. Most plugin authors resolve this stuff with time. But thanks for the examples :)