Generated by 🚫 Danger

I support the idea of not using non-GA dependencies.

Having said that, I don't really like the idea of downstream projects (ie: Sonar) conditioning our usage of libraries. We are otherwise conditioned (and forced) by them on when to upgrade to another major (and due to backwards compatibility issues, there is a good chance the 'when' is actually 'never' for them). Moreover, we may find other downstream projects following a separate schedule.

I see two possible ways forward:

1. We make a hard stance. We support whichever version we feel is right at any given moment in time and push for downstream project to do proper classloader isolation.
2. We acknowledge that logging may be an edge case and treat it separately. Doing so would probably require we setup our own PmdLogger abstraction within pmd-core and rescope that module to the pmd engine itself; moving the CLI support to either pmd-dist or a new module, and having that module provide the bridge between that and SLF4J. Downstream projects can therefore depend on pmd-core and provide their own bridge between PmdLogger and whatever backend they are keen on using.

I'd rather be pragmatic here - especially as it is logging, which is a cross-cutting concern. I'm not sure if there is even a proper way to do classloader isolation, if every library's log should end up in the same log channel (and sonar already seems to isolate the dependencies of the plugins with the only exception being slf4j).

Creating an own logging abstraction/wrapper doesn't seem to be a good idea either, see https://www.slf4j.org/faq.html#optional_dependency

So I'd acknowledge that logging is an edge case and simply downgrade. It's more important for me, that PMD is working in different environments than insisting on using slf4j2.