I must be misunderstanding. IIUC you are proposing that to eliminate optional dependencies we create a bunch of empty jars, presumably with a pom that has the dependency as required. How exactly does that help? Doesn’t that new, empty artifact just become an optional dependency? Isn’t it required during the build to allow the dependency to be resolved?
Ralph > On Jan 19, 2025, at 2:02 AM, Piotr P. Karwasz <pi...@mailing.copernik.eu> > wrote: > > Hi all, > > Maven is notably bad at handling optional dependencies, which are basically > ignored by consumers of the POM file. While Log4j Core 3 solves this problem > by not having **any** optional dependencies, we could backport this feature > also to Log4j Core 2. > > What do you think about adding empty artifacts in Log4j Core 2 for each > optional feature? They would work exactly like Spring Boot starters and pull > the required modules and dependencies into a user's project. For example > `log4j-async-logger` would depend on `com.lmax:disruptor`. > > The purpose of such artifacts would be double: > > * They would allow a smoother migration to Log4j Core 3 (just a version > bump). An empty `log4j-async-logger` from version 2.x, will be replaced with > a real JAR in version 3.x. > > * They would a semantic purpose: they would allow developers better > understand, why a certain dependency is in their stack. This is particularly > important in case of vulnerabilities in the dependencies. For example, if the > user has `log4j-config-yaml` as dependency and a CVE is published against > SnakeYaml, he can easily deduce that the CVE would only affect Log4j Core. > Even for an empty `log4j-config-yaml` we can publish a VEX statement that > says Log4j Core is not affected, since it does not parse YAML files from > untrusted sources. This scenario was discussed on `dev@kafka`[1]. > > I think we could backport from Log4j Core 3 as empty/starter JARs the > following modules: > > * `log4j-async-logger` for the Asynchronous Loggers feature. > > * `log4j-config-properties` and `log4j-config-yaml`. In the future we might > add `log4j-config-xml` in Log4j Core 3 as empty JAR, but with a `requires > java.xml` module descriptor. I am not sure if it is worth introducing a > `log4j-config-json` in version 2.x, since version 3.x does not require any > additional deps for JSON. > > * `log4j-compress` for alternative compression algorithms of the rolling file > appenders. > > * `log4j-conversant` and `log4j-jctools` for alternative queue factories of > the Asynchronous Appender. > > * `log4j-csv` for the CSV layout. > > * `log4j-jndi` for the optional dependency on `java.naming`. > > * `log4j-jdbc` and `log4j-jdbc-jndi` for the JDBC Appender and its JNDI > connection source. > > * `log4j-script` for the optional dependency on `java.scripting`. > > Piotr > > [1] https://lists.apache.org/thread/bnrr6djsd7nf2135ycpb9xmkwr7c8pt7 >
