It feels wrong to add support for a special development time tool in our runtime.
Gary On Thu, Jan 11, 2024, 1:58 PM Ralph Goers <ralph.go...@dslextreme.com> wrote: > 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. > >
