ppkarwasz commented on PR #2887: URL: https://github.com/apache/logging-log4j2/pull/2887#issuecomment-2310195040
> That said, when it comes to the motivation for this new plugin descriptor file format: > > * I don't see a pressing need (users are doing okay with the present tooling) > * Shading is a bad practice anyway There is no pressing need for this PR, I only created it as a response to [this `log4j-user@logging` thread](https://lists.apache.org/thread/fk9zd3gh7068d7brq82x48r7jvf1nvqy), when I realized that not all build tools have a resource handler for `Log4j2Plugins.dat`. I find shading a bad practice too: * **libraries** should not be shaded, since this provides a software supply chain risk. The current SBOM tools do not support shading (see CycloneDX/cyclonedx-maven-plugin#472), so user might be unaware that they have a vulnerable copy of a library on the classpath. MvnRepository doesn't recognize shaded libraries either (see [`pax-logging-log4j2`](https://mvnrepository.com/artifact/org.ops4j.pax.logging/pax-logging-log4j2), which contains a copy of `log4j-core`) and does not show CVE warnings. * **applications** should not be shaded, since there are better alternatives to create executable JARs, like the Spring Boot plugins. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
