Re: [log4j] ProGuard support in `log4j-api`

2024-01-11 Thread Gary Gregory
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 
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ı  wrote:
> >
> > 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)
> >  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.
>
>


Re: [log4j] ProGuard support in `log4j-api`

2024-01-11 Thread Ralph Goers
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ı  wrote:
> 
> 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)
>  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.



[log4j] ProGuard support in `log4j-api`

2024-01-11 Thread Volkan Yazıcı
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)
 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.