ppkarwasz commented on PR #4144: URL: https://github.com/apache/logging-log4j2/pull/4144#issuecomment-4809518196
> it breaks setups of users populating their `lib` folder with JARs manually. Furthermore, logging implementations (not APIs) by nature are provided to the class path in the last mile: when it is getting deployed. This can even be a deployment script: `java -cp log4j-core.jar:app.jar -Dlog4j2.configurationFile=/etc/log4j.xml com.acme.App` Both of these user groups will observe a failure due to any new transitive dependency. The first group is very real and is the reason we have **binary distributions**. I don't think however that this group uses new Log4j versions. The topic of the binary distribution is something I would like to discuss on the mailing list: it has a marginal cost (space on `downloads.apache.org` and a few downloads), but also a marginal usefulness. Regarding the second group, in my experience users don't add the logging implementation in the “last mile” as we would hope. A couple of years ago, I went into a small spree to prevent `logback-classic` or `log4j-core` from leaking into the classpath of consumers of Maven Central JARs. Projects usually add the dependency to an artifact that has a `main` method and can be used both as a library and the entry point of an application. The dependency should rather be in a “dist” module that creates a binary distribution. Anyway, even if projects add the logging implementation in the last mile, the process is usually not manual and the tool (Maven Assembly Plugin for example) is perfectly able to resolve transitive dependencies. For most applications `log4j-api` is a transitive dependency, not a direct one, so `log4j-core` is **not** dependency-free. -- 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]
