Yeah - if we add it to the code base that implies that we are testing it. I really don’t want to be in the position where we start adding customizations for every tool a user might be using. This is very much in line with our not wanting to keep adding more and more integrations .
Ralph > On Jan 11, 2024, at 11:36 AM, Volkan Yazıcı <vol...@yazi.ci> wrote: > > ProGuard <https://github.com/Guardsquare/proguard> – a GPL2-licensed, > widely used JAR optimizer and obfuscator in the Android world – doesn't > work with `log4j-api` out of the box. In summary, since Log4j uses > reflection, ProGuard needs to be configured to avoid removing certain Log4j > classes. A user has submitted (#2182) > <https://github.com/apache/logging-log4j2/pull/2182> the ProGuard > configuration addressing the issue. We can either distribute it in > `META-INF/proguard/log4j.pro` and make `log4j-api` work out-of-the-box with > ProGoard or simply document this. Given how certain PMC members are > strongly allergic to breaking backward compatibility even in major > releases, I am afraid distributing this as a part of `log4j-api` will > become a liability we cannot get rid of in our lifetime. I will share this > with the user and ask him to convert his PR to a documentation update. If > you disagree, please let me know.
